Re: compiling STAR staticaly under Linux

Joerg Schilling wrote:

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

In fact, it is:

( root@cookie ) #cat /etc/redhat-release

Red Hat Linux release 7.3 (Valhalla)

/usr/lib

( root@cookie ) #uname -a

Linux cookie 2.4.22 #2 Thu Oct 9 10:31:36 UCT 2003 i686 unknown

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.

Ok. So may be a faster option would be to find a source of LIBC,
butcher their gcvt() function and replace it with yours. Then
regenerate a new libc.a and link with that new one.

-rwxr-xr-x 1 root root 1343176 Apr 15 2002
/lib/libc-2.2.5.so

-rw-r--r-- 1 root root 2310808 Apr 15 2002 /usr/lib/libc.a

A 2.2.5 version seems to be available here:

http://ftp.gnu.org/gnu/glibc/

I don't want to risk more problems by using another Libc version than
the one on my system, although I see no reason why it should create
more problems. (appart from libc with dynamic links)

This new tendancy to force people to use Dynamic libs is getting
tiresome. I don't want to be forced to use Dynamic libs, because these
dynamics libs are not interroperable. One always get problems with them.

I'll let you know what happens. But may be I'll abort this if it takes
up too much time.