Re: Problem compiling (gcc? glibc?)
On Fri, 14 Jan 2005 1:07 am, David wrote:
> On Thu, Jan 13, 2005 at 12:37:14PM +1300, Andrew Walbran wrote:
> > On Thu, 13 Jan 2005 4:59 am, David wrote:
> > > On Wed, Jan 12, 2005 at 03:40:22PM +1300, Andrew Walbran wrote:
> > > > > > On Thu, 6 Jan 2005 18:20:35 +1300, Andrew Walbran
> > > >
> > > > wrote:
> > > > > > > I have recently started using Debian GNU / Linux, and have
> > > > > > > found that I am unable to compile anything with GCC.
> > > > > > > Compiling even a trivial program gives a number of
> > > > > > > 'undefined reference' errors:
> > > > > > >
> > > > > > > /lib/libc.so.6: undefined reference to
> > > >
> > > > [...]
> > > >
> > > > > > > Compiling with the -static flag succeeds without errors, but
> > > > > > > this is not really a solution.
>
> This sounds line it's in some way your ldconfig setup.
Where should I start looking?
>
> > > > > > > I am using the latest packages from the 'testing' section,
> > > > > > > including gcc 3.3.5-5 and glibc 2.3.2.ds1-20, on a Pentium II.
> > > > > > >
> > > > > > > I noticed that these errors refer to /lib/libc.so.6, whereas
> > > > > > > 'ldd /bin/echo' (for example) reports linking against
> > > > > > > /lib/tls/libc.so.6. I am not sure if this is relevant; what is
> > > > > > > the difference between the two libraries?
>
> Is /bin/echo the only file you can find that links thus? Actually, in
No. All programs appear to be linked against /lib/tls/libc.so.6. I've checked
echo, grep, gzip, kwrite, vi, mc, gedit. Other libraries from /lib/tls are
also used instead of their counterparts in /lib. (e.g. libm, libdl,
libpthread, librt, libresolv ...).
> this case, IIUC, echo is rarely called if you use bash (and perhaps
> others) because bash provides its own echo function. Out of curiosity,
> for any of these programs that have this odd linkage, find the package
> that contains this program. ( use dpkg -S <programname>). Then, do a
> dpkg --contents <deb-in-archive> | grep <some-part-of-program> for some
> deb you have in the archive, and compare the size, etc of the
> corresponding files. It appears to me that you have an oddball echo.
>
> > > One question. Did you do a fresh install of Debian or did you by any
> > > chance install over an existing install? FWIW, my /bin/echo links
> > > against /lib/libc.so.6
> >
> > I installed woody a while ago, then upgraded to sarge / testing with
> > apt-get.
>
> Then your libraries _ought_ to be correct. I've come all the way from
> potato to sarge by simply upgrading.
>
> > > Do you by any chance have an environment variable "LD_LIBRARY_PATH"
> > > set?
> >
> > No, LD_LIBRARY_PATH is not set.
> >
> > > If so, this might be causing the error. Also, "cat /etc/ld.so.conf"
> > > and
> >
> > $ cat /etc/ld.so.conf
> > /usr/X11R6/lib
> > /usr/lib/atlas
> > /usr/local/lib
>
> I have only the X11 entry in mine. I wonder.. I'm not that proficient
> with libc, but could it be that something in one of these directories is
> intercepting and redirecting your search path???
>
> > I've tried running ldconfig (as root), but it made no difference.
>
> As an experiment, in light of my previous paragraph, if you're not
> afraid to tinker with it, how about temporarily removing at least the
> atlas and local libs from the path and see if that helps?
I tried this suggestion (removing all but /usr/X11R6/lib from /etc/ld.so.conf
and running ldconfig), but it makes no difference - I still get the same
error when compiling.
I can't work out why ld.so is using /lib/tls rather than /lib. According to
the manpage for ld.so, it looks for shared libraries in LD_LIBRARY_PATH, then
those listed in /etc/ld.so.cache (created by ldconfig according
to /etc/ld.so.conf), and then in /usr/lib and /lib. None of these should
cause it to look in /lib/tls.
However, I have found that if I set LD_LIBRARY_PATH to _either_ /lib
or /lib/tls, gcc works fine and gives no errors. The resulting executable
links against /lib/tls/libc.so.6. Why would this be?
Andrew Walbran
Reply to: