Re: compiling STAR staticaly under Linux

Francois Vigneron <[email protected]> wrote:

> >Let me warn you: I asume that you will fail on Linux. glibc seems no 
> >longer to be suitable for static linking since about 5 years because 
> >of a rotten gcvt() implementation in glibc.

> On an old system with Redhat 8.xx, I do get a problem with gcvt(). This 
> might be solved by forcing some linker options to force the right gcvt() 
> function to be linked. Or may be I can depackage the libc and repakage 
> it after removing gcvt() and then force to link with my new modified 
> "libc". This is becoming time consuming.
>
> usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libc.a(efgcvt.o): In 
> function `gcvt':
> efgcvt.o(.text+0xb0): multiple definition of `gcvt'
> ../libs/i686-linux-cc//libschily.a(fconv.o)(.text+0x0): first defined here
> /usr/bin/ld: Warning: size of symbol `gcvt' changed from 400 to 51 in 
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libc.a(efgcvt.o)
> collect2: ld returned 1 exit status
> make[1]: *** [OBJ/i686-linux-cc/star_fat] Error 1

This is what I have in mind.

Glibc comes with a rotten version of gcvt(), so libschily does include 
a working one.

As glibc has the broken gcvt() implementation in the same file
as sprintf(), it will always be loaded. As the glibc people do not cleanly deal
with "weak" symbols, this all fails.



> On Redhat FC4, it seems that the static libc has got some dynamic links 
> to some dynamic libs.
> Or may be I don't understand what is happening.
>
>         ==> LINKING "OBJ/i686-linux-cc/star_fat"
> /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../libc.a(malloc.o)(.text+0x3040): 
> In function `malloc
> ':
> : multiple definition of `__malloc'
> OBJ/i686-linux-cc/mem.o(.text+0x0):mem.c: first defined here
> /usr/bin/ld: Warning: size of symbol `__malloc' changed from 50 in 
> OBJ/i686-linux-cc/mem.o to 350
>  in /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../libc.a(malloc.o)
> /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../libc.a(malloc.o)(.text+0x34cc): 
> In function `reallo
> c':
> : multiple definition of `__realloc'

This seems to be just another problem similar to gcvt().


> 0 in /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../libc.a(malloc.o)
> OBJ/i686-linux-cc/names.o(.text+0x221): In function `namegid':
> names.c: warning: Using 'getgrgid' in statically linked applications 
> requires at runtime the shar

This looks like a result of the Linux adoption to the Sun /etc/nsswitch.conf
idea. This requires dlopen() to work which is only possible in dynamic linking.


> /usr/src/star-1.5/libs/i686-linux-cc//librmt.a(remote.o)(.text+0x132): 
> In function `rmtgetconn':
> remote.c: warning: Using 'getservbyname' in statically linked a 
> pplications requires at runtime th
> e shared libraries from the glibc version used for linking

See getgrid()

> /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../libc.a(rcmd.o)(.text+0x1e9): 
> In function `rcmd_af':
> : warning: Using 'getaddrinfo' in statically linked applications 
> requires at runtime the shared l
> ibraries from the glibc version used for linking
> collect2: ld returned 1 exit status
> smake: Operation not permitted. *** Code 1 from command line for target 
> 'OBJ/i686-linux-cc/star_f

> May be a better answer would be to try to remaster the rescue CDROM of FC4 by adding the STAR programm to it. I'll first try to put it on floppy and see if it can execute on the FC4 rescue environment.
>
>
> It seems that I stand a better chance of getting a static exec with an old Redhat 8.x rather than FC4.

As I noted, the time of statical linking did end 2 years ago on Solaris
and it seems to end on Linux now.

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  
       [email protected]	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily