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!