I'm having trouble using libpng with Xcode 4.2 on OS X 10.7.1.
My program fails to launch with the error:
dyld: Library not loaded: /usr/X11/lib/libpng15.15.dylib
and:
Reason: Incompatible library version: glsl_test requires version 20.0.0 or later,
but libpng15.15.dylib provides version 17.0.0
All I'm doing is adding /usr/X11/libpng.dylib to the linked libraries, so where is this 'version 20' requirement coming from? Why isn't Xcode just requiring the version that's available? How do I go about telling my program that it's OK to use version 17?
Without knowing much about the intricacies of Xcode, it sounds like something else in your program requires a later version of the libpng library. This could even be something that is implicitly included by the build environment.
I'd double-check that you have a build environment that is compatible with your intended target. I'd also double-check that you're specifying the inclusion of the library using appropriate syntax (e.g., using -lpng vs. an explicit "/usr/X11/libpng.dylib").
Related
I just installed QT Creator with QT under Win10 to build an already existing project. (Under Ubuntu everything went fine running the Make file). I'm not an expert for QT therefore I'm not able to find out how to resolve the error:
C:\Qt\5.14.2\mingw73_64\include/QtCore/qfloat16.h:102:54: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:6590
Q_CORE_EXPORT static const quint32 mantissatable[];
My gcc version is 8.3.0 (x86_64-posix-seh, Built by strawberryperl.com project). Is there something missing or broken in the installation?
On windows, you generally need to have a Qt which was built with the same (or compatible, but that can be hard to verify) compiler and relevant build options, as what you are using to build your application.
I doubt you will find a pre-built Qt SDK for that version of gcc, so if you want to use it, you should build Qt from sources. It can be a bit tedious on Windows, there are a fewf prerequisites you have to get etc. I recommend you use the Qt online installer to install a MinGW version of Qt SDK, and matching version of MinGW (also offered by the Qt installer.
I just found out from qmake.stash, that the included script for creating the make file always referenced a false path for the gcc compiler. I therefore build i manually with the QT Creator and it worked as expected. So I guess the fault was due to different paths for gcc in the environmental variables.
Here is the bug, there is a link to the patch: https://github.com/msys2/MINGW-packages/issues/5006
Also you can just downgrade to mingw gcc 8.2.0
I am trying to get some older third-party software to compile on OS X 10.9. I've managed to get rid of most compilation problems by adjusting settings in the Makefiles, which were originally written for gcc probably around 2005. However, I currently don't know how to overcome this error for a C++ source file:
/utility.h:42:10: fatal error: 'ext/slist' file not found
I understand that ext/slist belongs to some version of STL. Has that version been superseded or does it have to be activated in any special way for Apple's version of Clang/LLVM (5.0 for OS X 10.9)?
If at all possible, I would prefer to compile this software with the pre-installed tools and not go through such steps as installing gcc via MacPorts.
BTW, these warnings also persist:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ext/hash_set:202:2:
warning:
Use of the header is deprecated. Migrate to
[-W#warnings] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ext/hash_map:209:2:
warning:
Use of the header is deprecated. Migrate to
[-W#warnings]
Slist is a singly linked list and was an extention included in libstdc++. Mac OS X has been moving away from libstdc++ toward libc++, which provides a C++11 standard library. C++11 provides a singly linked list under the name std::forward_list in the header <forward_list>.
I believe libstdc++ is still included in the developer tools, so you may also be able to switch your project back to that. If you're using an Xcode project you can select the library in the build settings, or ensure that the program is getting built with -stdlib=libstdc++
I'm building a large C++ project using cmake on ubuntu 12.04 and then taking the resulting binary package and trying to run it on ubuntu 11.04. However the program fails saying it needs glibc version 2.14 but can only find up to version 2.13.
How can I find out exactly why glibc=>2.14 is required?
Unlike most libraries, glibc versions its symbols. Every symbol is tagged with a value (e.g. "GLIBC_2.3.4") representing the version of the library where it's interface was last changed. This allows the library to contain more than one version of a given symbol and support binaries compiled against older versions while preserving the ability to evolve. You can see this detail with objdump -T /lib/libc.so.6.
Basically, something in your app was linked against a symbol that was changed since 11.04. Try objdump -T on your binary and see what tags it's looking for.
But broadly, backwards compatibility doesn't work like that in Linux. If you want something to run on older software, you should build it on older software. It's possible to set up a backwards-compatible toolchain on more recent distros, but it's not the default.
When you build your C++ project, it will link to the version of the glibc library on your 12.04 installation. What are the linker options in your build command?
Without knowing exactly what you are building, I'd say you might be better off building on 11.04 and then running on 12.04.
I'm currently programming an extension to a program, which only supports
i386 (and I am running amd64 Ubuntu 11.10). Whenever I compile my extension source
I need to use the -m32 flag to force 32 bit architecture (otherwise the program will not be able to load my extension). Sooner or later it is inevitable to avoid boost
thanks to its huge and stable library, which leads to my problem.
I want to use the boost filesystem, which uses OS specific function calls, which in turn leads to the requirement of a library file instead of only a header implementation. The problem is; I can't/don't know how to setup the boost filesystem (i386 version) on my amd64 machine. If I download a prebuilt (.deb) package for i386 and install it using -force-architecture it still fails complaining about dependencies.
So basically; how do I setup boost with 32bit (i386) architecture on my (amd64) system?
It seems as if I did it right all along but I was too dumb to realize how to properly link libraries with the GCC linker, coming from a Windows environment. You can easily compile boost libraries by using the -m32 flag and by setting up bjam properly. See the first answer in this question for details: How do I force a 32 bit build of boost with gcc?
I'm trying to port a project of mine on Mac OS-X.
As I developed my project using C++0X I needed a more recent version of GCC than the one provided with Xcode (even Xcode4), so I compiled GCC 4.6 on my Snow Leopards Mac.
My project does compile fine and it does start too on the computer I compiled it (OS-X 10.6.7) but when I transfer it to my MacBook (OS-X 10.5.8) it doesn't works.
It returns the following errors:
dyld: lazy symbol binding failed:
Symbol not found:
__ZNSo9_M_insertImEERSoT_ Referenced from:
/Users/zu/Desktop/OgreApp.app/Contents/MacOS/OgreApp
Expected in:
/usr/lib/libstdc++.6.dylib
dyld: Symbol not found:
__ZNSo9_M_insertImEERSoT_ Referenced from:
/Users/zu/Desktop/OgreApp.app/Contents/MacOS/OgreApp
Expected in:
/usr/lib/libstdc++.6.dylib
I understand that the program needs the libstdc++.6.dylib of the GCC 4.6.0 as this file contains the C++0x functions (despite the fact that my current test doesn't use any C++0x function) instead of the standard libstdc++.6.dylib usually included in the OS-X system.
So I tried the following:
to specify -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 in order to ensure backward compatibility with OS-X 10.5. But the error remains the same.
to verify the libstdc++.6.dylib path using otool -L and changing the shared library path using install_name_tool -change /opt/local/lib/gcc46/libstdc++.6.dylib #executable_path/../Libraries/libstdc++.6.dylib OgreApp (with a copy of the gcc 4.6.0 libstdc++.6.dylib in the Libraries folder) as suggested as answer of my previous question. But the error remains the same.
to statically link libstdc++ and libgcc using -static-libgcc - static-libstdc++. But it still returns the same error.
As my program use the Ogre framework, I applied the above manipulations to the Ogre executable embedded in the Ogre.framework too, but it doesn't change anything.
Does anyone can explain me how I'm supposed to deploy an application created with a non standard libstdc++ on another Mac computer installed with an older version (I guess the problem is the same with a computer running Snow Leopard as the program use the GCC 4.6.0 libstdc++) ?
Mac OS X 10.5 does not include a compatible copy of the GCC standard library. If you want your code to run on Leopard, you'll have to either modify it to compile under an older version of GCC, or you'll have to... well, really that's your only option.