Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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 )
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
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.
This is the content of my "/etc/ld.so.conf" file :
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
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.
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)
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.