Hi everybody,

For some days, I have been trying to compile an application that involves .pc ( Oracle Pro*C ) modules and C ones in a 64-bits Red Hat without success. The problem appears in the link phase:
[root@box1 ivor]# make -f Makefile ivor
gcc -O -m64 -DSUNOS56 -c -o main.o main.c
(I omit the rest of module compilations in shake of brevity, but all of them are successfully performed with exactly the same gcc command )

proc iname=sql

Pro*C/C++: Release 10.2.0.3.0 - Production on Tue Oct 2 10:00:20 2007

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: /home/oracle/product/10.2.0/precomp/admin/pcscfg.cfg

gcc -O -m64 -DSUNOS56 -c sql.c
gcc -O -m64 -DSUNOS56 -o ivor main.o getopt.o getopt1.o pflow.o process.o filelist.o environ.o cleanup.o error.o argv.o copy.o log.o config.o list.o configy.o configl.o testmode.o filelock.o sql.o -L/home/oracle/product/10.2.0/lib/ -lclntsh `cat /home/oracle/product/10.2.0/lib/ldflags` `cat /home/oracle/product/10.2.0/lib/sysliblist` -ldl -lm
process.o: In function `mkPrimInputFile':
process.c.text+0x213): warning: the use of `mktemp' is dangerous, better use `mkstemp'
/usr/bin/ld: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in cleanup.o
/lib64/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [ivor] Error 1
rm configy.c

The OS is Red Hat 4.1.1-52 (Linux version 2.6.18-8.1.10.el5xen), the Oracle DB is 10g and the Pro*C/C++ release is 10.2.0.3.0.

Apparently the error messages are due to a conflict between the code generated by the compiler and the library “libc.so.6”. This is the library:
[root@box1 ~]# ls -tl /lib64/libc.so.6
lrwxrwxrwx 1 root root 11 Aug 8 03:55 /lib64/libc.so.6 -> libc-2.5.so

To be honest, I do not know how to check if the library’s version is right. I have tried to find any reference in http://rpm.pbone.net/ without success.

On the other hand, the gcc version is gcc-4.1.1-52.el5.2. I have used yum to check if this is the last version, and apparently it is.

I have also tried to check if my ld configuration was right ( see http://www.linuxquestions.org/questi...d.php?t=453822 ), but the information that I got was not clear to me.

This is the content of my "/etc/ld.so.conf" file :
include ld.so.conf.d/*.conf

If I look at the directory above, I can see this files:

-r--r--r-- 1 root root 324 Aug 31 02:08 /etc/ld.so.conf.d/kernelcap-2.6.18-8.1.10.el5.conf
-r--r--r-- 1 root root 324 Jun 25 22:30 /etc/ld.so.conf.d/kernelcap-2.6.18-8.1.8.el5.conf

And their content are identical:

# This directive teaches ldconfig to search in nosegneg subdirectories
# and cache the DSOs there with extra bit 0 set in their hwcap match
# fields. In Xen guest kernels, the vDSO tells the dynamic linker to
# search in nosegneg subdirectories and to match this extra hwcap bit
# in the ld.so.cache file.
hwcap 0 nosegneg


Finally, I am using the following Makefile:

include $(ORACLE_HOME)/precomp/lib/env_precomp.mk

EXE = ivor

MAINOBJ = main.o getopt.o getopt1.o pflow.o process.o filelist.o \
environ.o cleanup.o error.o argv.o copy.o log.o \
config.o list.o configy.o configl.o testmode.o \
filelock.o sql.o

CC = gcc
CFLAGS = -O -m64 -DSUNOS56


$(EXE): $(MAINOBJ)
$(CC) $(CFLAGS) -o $(EXE) $(MAINOBJ) -L$(LIBHOME) $(PROLDLIBS)

pcp: pcp.o
$(CC) $(CFLAGS) -o pcp pcp.o -L$(LIBHOME) $(PROLDLIBS)

clean:
rm -f $(MAINOBJ) pcp.o $(EXE) pcp sql.c y.tab.c y.tab.h lex.yy.c


.SUFFIXES: .pc


.pc.c:
$(PROC) $(PROCFLAGS) iname=$*

.pc.o:
$(PROC) $(PROCFLAGS) iname=$*
$(CC) $(CFLAGS) -c $*.c


Well, sorry for the very long post. But I have tried to give the most relevant information that I have been able to get. Thank you very much in advance for your suggestions.

Regards,

Jose

It looks like you have 3 options:

1) You downgrade your glibc or obtain an older *non-TLS* glibc.

2) [SAFE] Modify your application's sources (in particular, cleanup.c) so that instead of declaring "errno" manually, it instead #includes "errno.h." Do similar things for other files.

3) [NONSAFE] Modify your application's sources (in particular cleanup.c) so that all global variables have __thread keyword specified as part of their declaration.

Pick either one. If you don't have sources, but only the object files, your only option is #1. Besides all this, unfortunately, I have no other way in mind to help you overcome your problem...

-Ilya

Correction: modify all non-application specific *extern* declarations into *extern __thread* -- that should make it safe.

Hi Ilya,

Thank you very much for you suggestions.

I tried the first option and the error vanished. Now I have to deal to another ones, but I think that they are easier.

Regards,

Jose

You're welcome, Jose. Good luck with the other errors.

Hi Ilya,

Ran into same problem - replacing explicit errno declaration with the include resolved the problem - Thanks.

Chris

Thanks icedogma!
The third option worked for me!

Hi everyone,

I met similar problem but with different case. I'm working on l4/fiasco and try to port some library into it. I've done successfully in porting libtiff, but when I compiled my program using that library, there's an error which is shown by error message below

ld: errno: TLS reference in /home/../l4linux_test/obj/l4/x86/lib/x86_586/l4f/libpthread.a(semaphore.o) mismatches non-TLS reference in /home/../l4linux_test/obj/l4/x86/lib/x86_586/libtiff.so
/home/../l4linux_test/obj/l4/x86/lib/x86_586/l4f/libpthread.a: could not read symbols: Bad value

I have tried solution 2 which is given by ilya by including errno.h in compiling libtiff library, but I'm still facing the same problem. I'm going to try solution 3, but this error is caused by libtiff.so which means compiled library instead of my application source. So, I'm not sure what should I do now.

regards,

irvanda

Irvanda:

Make sure that both libtiff.so and libpthread.a were each compiled, assembled, and linked by the same toolchain (e.g. gcc of the same version).

A cursory inspection hints that your libpthread.a was compiled with a compiler that assumes presence of thread local storage support. I don't know if this exists in L4. Make sure your pthread lib gets compiled by the correct compiler. Ignore this, if it came already as part of the whole package. In this case, make sure that your libtiff files get compiled with TLS-supporting compiler (also grep for all instances of "__thread", and make sure that they are not #undef'ined or something along those lines)


Ilya

Hi Ilya,
I'm sure that all the packages in fiasco are compiled using the same version of gcc. I've made some modification in my ported libtiff, then I got this error message:

libuc_c.a(errno.o) section .tbss mismatches non-TLS reference in libtiff.a(tif_unix.o)

I've checked the tif_unix.c and the errno.h is declared in #include <errno.h> which I think there is no problem with this file.

You can check the tif_unix.c source code in this link https://github.com/Itseez/opencv/blo...iff/tif_unix.c

regards,
Irvanda

I'm sorry Ilya, you are right. I compiled the ported library with different compiler. I just found that the default compiler for fiasco is uClibc, but I compiled the ported library using gcc. That's the source of the problem. Thanks for your suggestion.

regards,
Irvanda