I want to force new GCC 12 on my old debian (that only has GCC 6 by default) to use fresh libstdc++ headers with new header-only features, but link with old stdlibc++,gcc_s (and other system/compiler libs used by GCC6) to keep binary compatibility with native runtime of old debian (so that users of old GCC6 can link with my binaries without having GCC12).
Of course I know that some functionality in the old runtime will be missing, and ABI is also different, but I guess I can fight with that. Afterall RedHat seems to be using similar scheme for their devtoolset packages (they try to link missing functionality of new runtime statically to your binary if these symbols are not found in native old runtime)
So far I am stuck with -L arguments that GCC is passing to ld.
Here is complete output of /usr/local/gcc12/bin/x86_64-linux-gnu-gcc-12 main.cpp -Wl,-v -v command for simple hello-world main.cpp:
https://pastebin.com/JhYSfg4x
The question: Where does GCC take all these -L paths from, and how do I remove/modify them? I don't want to accidentally link with new version of libraries that were built with GCC12:
-L/usr/lib/gcc/x86_64-linux-gnu -L/usr/local/gcc12/lib/gcc/x86_64-linux-gnu/12 -L/usr/local/gcc12/lib/gcc/x86_64-linux-gnu/12/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc -L/usr/local/gcc12/lib/gcc/x86_64-linux-gnu/12/../../.. /tmp/ccXfhCs4.o
System ld.conf does not mention any paths to /usr/local/gcc12 folder.
-nostdlib and -nodefaultlibs are removing some standard -l flags, but they are not doing anything to -L flags.
Update: I ended up just removing all *.a, .so, *.la files from include, lib and lib64 folders of gcc12, and I also added -L path to native libraries. This way I am sure gcc12 can't pickup one of its libraries for li nking. Not sure if this is good solution, but it works.
Related
I am trying to compile a program which uses GSL, in fact I am already able to compile it successfully on my local machine using
g++ -o program program.c prog0.o -L/usr/local/lib -lgsl -lgslcblas -lm
My problem is that I need to compile this program on a work machine in a shared system, but I know the program will not compile with an up to date version of GSL, so I need to install and use an older version.
I did this on my own system using the default installation, so the relevant files are located in /usr/local/lib on my local machine, and the compilation works for me with the above command.
But since the work machine is in a shared system, I cannot mess with the default directories, so I installed the correct GSL version on the work machine in my directory under /home/myname/gsl/.
So on the work machine the folder /home/myname/gsl/lib contains the same relevant files as the folder /usr/local/lib on my machine.
Now I did various attempts to try and tell g++ to use this custom installation folder, which I thought would come down to
g++ -o program program.c prog0.o -L/home/myname/gsl/lib -lgsl -lgslcblas -lm
but no success. No matter what I did g++ always used the GSL version installed on the shared system, even using just
g++ -o program program.c prog0.o
I only started programming C/C++ not long ago and only know the very basics of how to compile programs, so this linking thing is still always confusing me..
But as far as I can tell -L/dir/ should tell g++ to use the library in /dir/ and -lgsl -lgslcblas are the files which it should look for in that library... ?
But it seems g++ doesn't care what library I tell it here, it always seems to use whatever is in the PATH of the shared work system, which seems to include this up-to-date version of GSL that I cannot use. But I also cannot change the PATH since I only have access to my own subdirectories on the work system..
So how do I tell g++ to ignore the default version of GSL and use the one I installed manually at /home/myname/gsl/ ?
I figured out the answer, it is actually simple. The problem was just my lack of understanding proper usage of outside libraries and trying to fix the compilation command was the wrong approach.
In the code in program.c, gsl was included with
#include <gsl/gsl_blas.h>
and so on. Of course, the "<>" directly tell the compiler to look in known include directories, where the up-to-date GSL is installed on the shared system.. So the way to use a custom version was just to instead use
#include "/home/myname/gsl/lib/gsl_blas.h"
and so on, directly specifying that I want to use my custom installation.
I then compiled with
g++ -o program program.c prog0.o /home/myname/gsl/lib/libgsl.so /home/myname/gsl/lib/libgslcblas.so -lm
and it compiles successfully.
(This brought up some other unclarities for me, but at least this specific problem is solved.)
I want to use gtest but execution tells me
./netTest: error while loading shared libraries: libgtest.so.0:
cannot open shared object file: No such file or directory
What are standard paths in that gcc linker looks for libs
What is standard path of Debian to store libs
How do I add libpaths to g++ (-L flag correct?)
Note on 2: I ask because the libs of gtest are in /usr/local/libs/ but in there is just python and gtest. All other libs are in /usr/lib/. Hence i guess the gtest installer made something wrong.
PS. Perhaps you could just instal the Debian libgtest-dev package (if there's one).
What are standard paths in that gcc linker looks for libs
You can see it with gcc -v -x c /dev/null -o /dev/null 2>&1 | grep LIBRARY_PATH
What is standard path of Debian to store libs
Perhaps you meant where the dynamic loader will look for shared libraries.
Check /etc/ld.so.conf and/or files in /etc/ld.so.conf.d/.
How do I add libpaths to g++ (-L flag correct?)
You can use the --rpath option to ld. However, I would suggest using it only during development and not in deployment.
You can also set LD_LIBRARY_PATH to the location of your libgtest.so.0.
The answer to the preceeding problem. gTest does not use precompiled libs anymore.
Use of precompiled libgtest Not Recommended
-------------------------------------------
The Google C++ Testing Framework uses conditional compilation for some
things. Because of the C++ "One Definition Rule", gtest must be
compiled with exactly the same flags as your C++ code under test.
Because this is hard to manage, upstream no longer recommends using
precompiled libraries [1].
-- Steve M. Robbins , Sat, 21 Apr 2012 17:00:56 -0500
Well doesnt surprise me anymore why I did not find the library in Wheezy :)
I have a problem with the implicit LIBRARY_PATH modification of g++ between two versions (g++ -v gives this info). I set the LIBRARY_PATH to a single local directory where I have custom libraries. However, it turned out that only one version of the g++ (let's call it version A) correctly linked, the other (version B) linked to the system-default, which was not desired. Apparently, the order of directories was mixed up and my specification was not properly respected. It is a similar issue to LIBRARY_PATH not used before /usr/lib anymore in gcc 4.2 and later? although not with these versions.
Somehow I came along the idea to have a look at the specs files of the two different versions (got them via g++ -dumpspecs > specs). I then tried to see if running the version of g++ (B; that was producing the *un*expected modifications) with the specs file of the other version (A) would still yield that modification and to my relief the LIBRARY_PATH was now exactly as I expected it (matching version A)!
I further traced down the place of this weird modification to happen at the following line:
. !m64 !m32;.:../lib64 m64 !m32;.:../lib32 !m64 m32;
Besides appearing to affect the setting/modification of LIBRARY_PATH, I sadly have no clue what this line means.
Therefore I hope that some of you is able to "decipher" this line and explain what it means so that I can try to modify it according to my requirements.
Thank you!
That line affects how libraries are found relative to GCC's $PREFIX/lib directory (where $PREFIX is the directory GCC was installed to.)
There are three parts to it:
$PREFIX/lib/. is used when neither -m32 or -m64 is used on the command-line.
$PREFIX/lib/.:$PREFIX/lib/../lib64 is used when -m64 is used.
$PREFIX/lib/.:$PREFIX/lib/../lib32 is used when -m32 is used.
This suggests to me you are using Debian or Ubuntu, I don't think a vanilla GCC build from the FSF sources would have that in the specs. Were both your GCC versions from .deb packages or did you install them yourself? (The Multi Arch support in recent Debian/Ubuntu releases moves library directories and so breaks vanilla GCC, I think Debian and Ubuntu patch the GCC code for their .deb packages.)
Could you add the output of linking with g++ -v for each of your versions, to see the exact library search paths used by each version?
Also, why not just use -L instead of LIBRARY_PATH? Directories specified with -L always come first, before the system dirs or GCC's own dirs or the ones specified in LIBRARY_PATH.
my custom built gcc 4.6.0, installed in my home directory, on ubuntu 10.04, links the system libstdc++ instead of the custom built one, most of the time (as evidenced by ldd). to be more puzzling, using this newly built gcc, custom compiled openmpi libraries are linked correctly, and this is the only software i have compiled that behaves ok. does anybody have any explanation for this, or a workaround?
thanks
Isn't there an option to statically link the libstdc into the gcc when you configure it? --disable-shared if I understand how it works correctly. Worst case make another compile of gcc with that switch and see if you run into the issue.
I don't know why this isn't detailed more clearly on the GCC website for end-users. The GCC FAQ clearly states this is a common problem wrt libstdc++. Environment variables are troublesome. Wrapping the linker, nobody knows how to do that. Editing /etc/ld.so.conf isn't an option. Adding -Wl,-rpath everywhere, come on. The easiest solution is the specs file. For a typical 64-bit x86 Linux system, go into your custom gcc installation, in dirname `g++ -print-libgcc-file-name`and then run g++ -dumpspecs > specs. Edit that file, find the *link_command: section. After %(link_libgcc) add -rpath /home/user/bin/gcc-9/lib64 (of course use your own path). Or add the same rpath to end of *link: section. Alternatively, configure gcc with --with-specs='%{!static:%x{-rpath=/home/user/bin/gcc9/lib64} %x{-enable-new-dtags}}' . Enjoy your own C++ compiler that generates binaries that just work.
See also:
GCC specs file: how to get the installation path
Linking g++ 4.8 to libstdc++
How to configure libstdc++ with GCC 4.8?
I have been trying to produce a statically linked "single binary" version of my game for windows. I want to link with sdl, sdl_image and sdl_mixer which in turn pull in a few support libraries. Unfortunately I haven't found a way to get them all to compile and link using cygwin/mingw/gcc. As far as I can tell all existing public versions are only shared libraries / dlls.
Please note that I'm not talking about licencing here. The source will be open thus the GPL/LGPLness of sdl is not relevant.
When compiling your project, you need to make just a couple changes to your makefile.
Instead of sdl-config --libs, use sdl-config --static-libs
Surround the use of the above-mentioned sdl-config --static-libs with -Wl,-Bstatic and -Wl,-Bdynamic. This tells GCC to force static linking, but only for the libraries specified between them.
If your makefile currently looks like:
SDLLIBS=`sdl-config --libs`
Change it to:
SDLLIBS=-Wl,-Bstatic `sdl-config --static-libs` -Wl,-Bdynamic
These are actually the same things you should do on Unix-like systems, but it usually doesn't cause as many errors on Unix-likes if you use the simpler -static flag to GCC, like it does on Windows.
Via this SDL mailing list post it seems that the sdl development tools ship with a sdl-config script that you can use with the --static-libs flag to determine what linker flags you need to use.
Environment: VMWare Virtual Machine with Windows 7 x64 and Equipment we Dev c + + build 7.4.2.569, complilador g+ + (tdm-1) 4.6.1
Once, SDL2-2.0.3 API installed as configuration Dev c ++ is not very clear what I've done as tradition requires command line.
The first problem is that Windows 7 appears to have changed the methodology and they go to his ball. Inventory. Ref. https://stackoverflow.com/users/464581/cheers-and-hth-alf
After the first hurdle, SDL_platform.h is that bad, it's down another, I do not remember where I downloaded, but the next does not work in the indicated version.
We must put SDL2.h ls in the directory of the executable.
D:\prg_desa\zsdl2>g++ bar.cpp main.cpp -o pepe1 -ID:\SDL2-2.0.3\i686-w64-mingw32\include\SDL2 -LD:\SDL2-2.0.3\i686-w64-mingw32\lib -lmingw32 -lSDL2main -lSDL2 -mwindow
I've finally compiled and works SDL2 testing.
That's because the SDL libs are under the LGPL-license.
If you want to static link the libs (you can do that if your recompile them. It needs some hacking into the makefiles though) you have to place your game under some compatible open source license as well.
The SDL-libs come as shared libraries because most programs that use them are closed source. The binary distribution comes in a form that most people need.
On my system (Ubuntu) I have to use the following flags:
-Wl,Bstatic -lSDL_image `sdl-config --libs` -lpng12 -lz -ltiff -ljpeg -lasound -laudio -lesd -Wl,-Bdynamic `directfb-config --libs` -lpulse-simple -lcaca -laa -ldl
That links SDL, SDL_image, and many of their dependencies as static. libdl you never want static, so making a fully-static binary that uses SDL_image is a poor idea. pulse,caca,aa, and directfb can probably be made static. I haven't got far enough to figure them out yet.