I have 3rd party libraries for my mac applications which used to link nicely to my application with the previous version of Mac OS X.
I have upgraded to Snow Leopard and now g++ linker complains:
ld: warning: in /Users/paul/Projects/3rdPath/NHUI/Lib/mac32/libNHUI.a, file is not of required architecture
The link also fails to locate functions from this library.
Do I need Snow Leopard versions of each 3rd party library or can I provide some compiler/link switch which could allow me to build like I did in the previous Mac OS X version.
Thank you,
Paul
I don't even own a Mac so feel free to disregard this, but your path has "mac32" in it, which suggests to me that it's a 32 bit library. "architecture" in computers usually refers to 32/64 bit CPU architectures, and I've heard that Snow Leopard has a big emphasis on migrating to 64 bit apps. As such, my first blush impression is that you are using a 32 bit library which Snow Leopard is warning you away from.
Hope that helps you get going in the right direction!
My guess is you're compiling 32/64-bit Universal, but the library itself is only 32-bit. While ideally you should get a 64-bit version of the library, for the time being you should just turn off 64-bit compilation of your application.
Related
I tried to install edge TPU compiler on my raspberrypi 3b+ but apparently it is no longer supported on 32bit. Can I install compiler on a 64bit machine, compile my code, turn it into a code readable by the edge tpu and bring this code back and run it on my raspberry pi? Or will there be conflict of some sort?
As far as application goes:
You can write your application code on the rpi. The code that you compiles on an x86-64 machine won't be executable on the rpi due to architecture differences. Unless you are using a cross compiler.
Now on the edgetpu compiler:
The edgetpu compiler can only be installed on the x86_64 machine, although since the format of the model is the same for all platform (flat buffer), you can use the same model compiled on the x86_64 platform on your rpi just fine!
The question says it all. I need to cross-compile for a Cyrix CPU. The system the compiler (doesn't have to be gcc) needs to run on is a 64bit Kubuntu, with an i5 processor. I couldn't find anything useful googling, except for a piece of information saying that "Cx486DX is software-compatible with i486". So I ran
gcc -m32 -march=i486 helloworld.c -o helloworld486.bin
but executing helloworld486.bin on the Cyrix machine gives me a floating point exception. My knowledge about CPUs is rather limited and I'm out of ideas now, any help would be really appreciated.
Unfortunately you need more than just a compiler that generates instructions for the 486. The compiler libraries, as well as any libraries that are linked in statically should be suitable as well. The GCC version included in most current Linux distributions is able to generate 486-only object files (I think), but its libraries and stub objects (e.g. crtbegin.o) have been pre-generated for 686 CPUs.
There are two main alternatives here:
Use a Linux build system that is compiled for 486 itself, either in a VM or in a chroot jail. Unfortunately getting a modern Linux distribution for the 486 is a bit of an issue - every single major distribution has moved on. Perhaps a (much) older Linux distribution would be of help?
Create a full cross-compiler toolchain for the 486. You can then cross-compile separate versions of all needed libraries and have your build scripts use them. Quite honestly, ensuring that nothing from the (usually 686-based) build host slips through to the build result is not very easy. It oftens amounts to cross-compiling a whole Linux system from scratch, ala CLFS.
An automated cross-compiler toolchain build script, such as crosstool-ng might be of help.
Could you add more details about your target system? Is it an embedded system or just an old PC? What OS is it using? Would it be possible to just run your compile in a VM with a version of the target OS?
I am a newbie at this and yesterday I installed Win 8.1 x64 so I would like to use the most suitable program for making my tasks in C/C++.
Thanks
MinGW supports only 32 bit binaries, TDM supports 32 and 64 bit binaries (with usage of MinGW's API's).
If you need a good GCC for Windows, with the drawback of 32 bit only,
use MinGW.
If you want to build 64 bit binaries too, you can use TDM.
Both released GCC 4.8 approximately at the same time, so there's no real difference in up-to-dateness.
My recommendation: Use the 3rd alternative: MinGW-w64 instead - it's a extended MinGW with support for 64 Bit. See here for a short description of MinGW-w64.
Whatever choice you make, better use official developers website for downloading (not Orwell's) to get most up-to-date version.
MinGW
MinGW-w64
TDM-GCC
Btw., you'll find a good overview there, what makes one special about the others.
NB: the homepage of mingw-w64 used to be on sourceforge but is now at http://mingw-w64.org ; links have been updated accordingly.
For those interested in 32-bit binaries:
Note the code::blocks IDE comes with MinGW, but the compiler is the 32-bit version of TDM-GCC. The TDM version has static runtime linkage by default which makes executables portable to systems without MinGW installed. The TDM-gcc compiler also seems to implement the latest gcc version faster than the other projects.
The MinGW distribution also doesn't use posix emulation to access threads in Windows (unlike MinGW64 or TDM64). There is a separate download source for the headers providing C++11 compliant and functionality for MinGW.
I'm try to debug PostgreSQL in Eclipse / Netbeans / QtCreator on Mavericks (OS X 10.9).
I have tried various compilers (GCC 4.2, CLang) in the various IDEs, different debuggers (GDB, LLDB), but I haven't found a configuration that works - especially in the sense that I can debug the code properly.
I'm currently trying with GCC 4.2 and GDB. I have installed GCC via homebrew and also certified gdb. I can compile the PostgreSQL source code and run it. However, each time I try to attach the debugger to the running threads, I always (independent of IDE) the following error:
Mach error at "darwin-at.c:726" in function "void darwin_resume_thread(struct inferior *, darwin_thread_t *, int, int)": (os/kern) failure (0x5).
Do you have any ideas what this means? Or do you have maybe a clue how I can get PostgreSQL to compile, debug and run on OS X 10.9?
Use the compiler and debugger from XCode, not one installed from Macports / Homebrew / whatever. Build with llvm and debug with lldb.
You might need to install XCode 5 for this to work on your new OS X.
Apple tends to rather freely break kernel interfaces, etc, when they update the OS, and rarely document these changes for 3rd parties. So it sometimes takes time for 3rd party tools to catch up and work on the latest OS X. In this case it seems reasonably likely that they've messed with the debug interfaces used by gdb.
If you still have issues when using the XCode 5 toolchain, post about that with specifics. The current question is a little bit of everything, so it's hard to pin down details.
Given that this is a Mach error (i.e. the kernel is complaining) it's also possible you've got a 3rd party driver or utility that's causing issues with a hook. Check what kernel extensions you've got installed.
Sorry if this is an obvious question, but I've found surprisingly few references on the web ...
I'm working with an API written in C by one of our business partners and supplied to us as a .so binary file, built on Fedora 11. We've been testing out the API on a Fedora 11 development machine with no problems. However, when I try to link against the API on our customer's target platform, which happens to be SuSE Enterprise 10.2, I get a "File format not recognized" error.
Commands that are also part of the binutils package, such as objdump or nm, give me the same file format error. The "file" command shows me:
ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
and the "ldd" command shows:
ldd: warning: you do not have execution permission for `./libuscuavactivity.so.1.1'
./libuscuavactivity.so.1.1: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./libuscuavactivity.so.1.1)
[dependent library list]
I'm guessing this is due to incompatibility between the C libraries on the two platforms, with the problem being that the code was compiled against a new version of glibc etc. than the one available on SuSE 10.2. I'm posting this question on the off chance that there is a way to compile the code on our partner's Fedora 11 platform in such a way that it will run on SuSE 10.2 as well.
I think the trick is to build on a flavour of linux with the oldest kernel and C library versions of any of the platforms you wish to support. In my job we build on Debian 4, which allows us to officially support Debian 4 and above, RedHat 3,4,5, SuSE 10 plus various other distros (SELinux etc.) in an unofficial fashion.
I suspect by building on a nice new version of linux, it becomes difficult to support people on older machines.
(edit) I should mention that we use the default compiler that comes with Debian 4, which I think is GCC 4.1.2. Installing newer compiler versions tends to make compatibility much worse.
Windows has it problems with compatability between different realeases, service packs, installed SDKs, and DLLs in general (DLL Hell, anyone?). Linux is not immune to the same kinds of issues.
The compatability issues I have seen include:
Runtime library changes
Link library changes
Kernel changes
Compiler technology changes (eg: pre and post EGCS gcc versions. This might be your issue).
Packager issues (RPM vs. APT)
In your particular case, I'd have them do a "gcc -v" on their system and report to you the gcc version number. Compare that to what you are using.
You might have to get hold of that version of the compiler to build your half with.
You can use Linux Application Checker tool ([1], [2], [3]) in order to solve compatibility problems of an application between Linux distributions. It will check your file formats and all dependent libraries. It supports almost all popular Linux distributions including all versions of SuSE and Fedora.
This is just a personal opinion, but when distributing something in binary-only form on Linux, you have a few options:
Build the gamut of .debs and .rpms for every distro under the sun, with a nominal ".tar.gz full of binaries" package for anything you've missed. The first part is ideal but cumbersome. The latter part will lead you to point 2 and 3.
Do as some are suggesting and find the oldest distro you can find and build there. My own opinion is this is sort of a ridiculous idea. See point 3.
Distribute binaries, and statically link where ever you can. Especially for libstdc++, which appears to be your problem here. There are seemingly very many incompatible versions of libstdc++ floating around, which makes it a compatibility nightmare. If you can't link statically, you can also put *.so files alongside your binary, and use stuff like LD_PRELOAD or LD_LIBRARY_PATH to make them link preferentially at runtime. Note that if you take this route you may have to comply with LGPL etc. since you are now distributing other people's work alongside your project.
Of course, distributing your project in source form is always preferred on Linux. :-)
If the message is file format not recognized then the problem is most likely one mentioned by elmarco in a comment -- namely, different architecture. It might (I'm not sure) be a dynamic linker version mismatch, but that would mean the .so file was built with an ancient dynamic linker. I do not believe any incompatibility in libc could cause this -- they could cause link failures and runtime problems (latter very rarely), but not this.
I don't know about Suse, but I know fedora likes to stay on the bleeding edge. So you may very well be right about library versions. Why don't you ask and see if you can get the source code and build it on your Suse machine?