Re: compiling STAR staticaly under Linux

Joerg Schilling wrote:

Francois Vigneron <[email protected]> wrote:

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.

I am tackling the problem by the wrong end. It will be easier to modify
the "star" code and to change the name of gcvt() in star so that it
call your local gcvt() instead of trying to fidle with the source code
of libc. I'll change gcvt() to gcvt2() and change it in your lib. That
way, I should avoid problems when linking with libc.

I'll try that next week.