On Jan 24, 2008 5:12 PM, Andrew Haley <aph@xxxxxxxxxx> wrote: > Angelo Leto wrote: > > On Jan 24, 2008 12:18 PM, Andrew Haley <aph@xxxxxxxxxx> wrote: > >> Angelo leto wrote: > >>> Hi, I'm trying to build statically all the gcc executables in order to > >>> generate a portable compiler package, in particular I need a package > >>> which is not dependent from a specific dynamic loader version > >>> (ld-linux.so.2), could you please help me to find a way to obtain > >>> this? > >>> For instance I can run gcc using the command "ld-linux.so.2 > >>> ~/mygcc/usr/bin/c++", but c++ then calls cc1plus which also needs > >>> ld-linux.so.2 .... > >> The short answer is to set the makefile args to that gcc links with > >> -static. Simply "make LDFLAGS=-static" might work for you. > > > > I already tried this, but seems not to work. > > It works for me. You need to tell us in what way it seems not to > work for you. We can't get far by guessing. The steps I execute are: 1) I downloaded gcc-4.2.2 from ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.2.2/gcc-4.2.2.tar.bz2 2) enter gcc-4.2.2 3) make LDFLAGS=-static 4) /usr/local/src/gcc-4.2.2 # ldd host-i686-pc-linux-gnu/gcc/cc1plus linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/libc.so.6 (0xb7e94000) /lib/ld-linux.so.2 (0xb7fdd000) > > >> The long answer: > >> > >> Usually, people who want to do this don't know what they're doing, and > >> people who do know how to do it wouldn't consider doing it because > >> they know all the problems it will cause. > > > > Question: which kind of problems could happen if I build gcc without > > architecture specific optimizations? > > None that I'm aware of, but I'm not sure of the relevance of that question. > > >> When you build gcc you're building it for a specific host/target > >> combination, and configure autodetects properties of both. It doesn't > >> usually make much sense to use a gcc that's been built for one host on > >> a different host. > > > > I'm working on applications which are data critical, so when I change > > a library on the system there is the risk that results may be > > different, so I create a repository with the critical libraries, and I > > upgrade the libraries on repository only when it is needed and > > independently from the system libraries (I do this in order to upgrade > > the productivity tools and their related libraries without interacting > > with the libraries linked by my application). Obviously when I change > > the compiler I obtain different results on my applications, so my idea > > is to create a "development package" which includes my critical > > libraries and also the compiler in order to obtain the same result > > (always using the same optimizations flags) on my application also > > when I'm compiling on different Linux installations. > > All fine and good, but I don't understand why that requires you to link > gcc itself statically. gcc doesn't need very many libraries and you > should be able to include the ones you need. because I want to run gcc also on linux installed with different version of glibc. > > Even better, build gcc dynamically on the older box. I tryied, but does not work on linux with new libc ... > > > I guess that the same gcc static binary (e.g. compiled for generic > > i386 architecture) should give me the same output on different linux > > environments running on i386 machines. Is there any reason for which > > this might not be true? > > You have to be very careful when linking _anything_ statically against > libc, in particular. See http://people.redhat.com/drepper/no_static_linking.html i will carefully read it. > > >> Sometimes, however, people build gcc on an old operating system > >> version and it will run on a newer version. That makes sense for > >> cross-compilers, in particular. > >> > >> So, can I ask you what you are really trying to do? Is it that you really need to run on some ancient Linux that really doesn't have > >> ld-linux.so.2? > > > > All the linux on which I run the applications do have ld-linux.so.2, > > but it is different from a glibc version to another. For example when > > I use a different version of ld-linux.so.2 I obtain the following : > > > > .... > > /home/test/svn/external-pkg/gcc_i386_march_pentium4/usr/libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus: > > relocation error:/home/test/svn/external-pkg/gcc_i386_march_pentium4/lib/libc.so.6: > > symbol _dl_tls_get_addr_soft, version GLIBC_PRIVATE not defined in > > file ld-linux.so.2 with link time reference > > > > so I cannot use the same ld-linux.so.2 because they are different. > > The problem here looks like you have a different version of libc and ld-linux.so.2. > They're a pair. You can't take them from different versions. I know, in fact I want to use the gcc compiled using libc 2.6 on a system whith libc 2.3, and to do this you must run the c++ using the command: ld-linux.so.2 c++ where the loader is the one coming with libc 2.6. And this work, but gcc call cc1plus and it also need to be executed using the ld-linux.so.2 from libc v2.6. bye. Angelo > > Andrew. >
