missing libraries under Kubuntu 12.04, 64 bit

[geezers]

Trying to compile and link some programs I wrote many years ago and have been using often. I last compiled under Kubuntu version 10 and decided to update and compile new features.

Using the same make file that worked for years, but getting linker errors for unresolved externals. The compilation gives me warnings about needing a format string for fprintf, but that is because the format string used has no '%' specifiers (I assume that is the reason it doesn't like the format string) and about ignoring function return values. I was going to fix those but decided to leave as is. Other than the warning messages, the compilation gives no errors.

The relevant make file line is:

$(CC) -o $@ -ldl -rdynamic $(OBJS)

CC is defined simply as gcc and OBJS is the list of object files.

The linker error messages are:

home$ make
linking
gcc -o qtgrep.bin -ldl -rdynamic buffer.o displayu.o findfile.o getopt.o grepdfa.o date.o re_compile.o re_exec.o re_read.o re_write.o kw_compile.o kw_exec.o kw_read.o kw_write.o scan.o set_expr.o read_pat_file.o free_pat.o write_pat_file.o memory_fun.o
set_expr.o: In function `QTGrep_load_compiled_searches':
/home/terry/Source/QTGrep_Multiple/set_expr.c:2036: undefined reference to `dlclose'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2042: undefined reference to `dlerror'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2045: undefined reference to `dlopen'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2047: undefined reference to `dlerror'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2052: undefined reference to `dlsym'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2053: undefined reference to `dlerror'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2067: undefined reference to `dlerror'
collect2: ld returned 1 exit status
make: *** [qtgrep.bin] Error 1
 
I used locate and got:

home$ locate libdl.
/dos/Vista/cygwin/lib/libdl.a
/lib/i386-linux-gnu/libdl.so.2
/lib/x86_64-linux-gnu/libdl.so.2
/lib32/libdl.so.2
/usr/lib/x86_64-linux-gnu/libdl.a
/usr/lib/x86_64-linux-gnu/libdl.so


I created links in /lib as:
/lib/libdl.a to /usr/lib/x86_64-linux-gnu/libdl.a
and
/lib/libdl.so to/usr/lib/x86_64-linux-gnu/libdl.so

hoping that would solve the problem. No Joy.

So I decided that is was time to ask the experts and found this mailing list. The answer is probably simple to those in the know, but I ran out of things to try for now. Will keep trying, but thought it quicker to ask.

Thanks for your help on this.

[Marc Glisse-6]

On Sat, 2 Jun 2012, geezers wrote:

> Using the same make file that worked for years, but getting linker errors
> for unresolved externals. The compilation gives me warnings about needing a
> format string for fprintf, but that is because the format string used has no
> '%' specifiers (I assume that is the reason it doesn't like the format
> string) and about ignoring function return values. I was going to fix those
> but decided to leave as is. Other than the warning messages, the compilation
> gives no errors.

If you want advice on those, you should show the exact message and the
code...

> The relevant make file line is:
>
> $(CC) -o $@ -ldl -rdynamic $(OBJS)

If A depends on B, put A before B on the line (A is $(OBJS) and B is
-ldl).

> I created links in /lib as:

Never do that!

--
Marc Glisse

[geezers]

Marc Glisse-6 wrote:

On Sat, 2 Jun 2012, geezers wrote:

> Using the same make file that worked for years, but getting linker errors
> for unresolved externals. The compilation gives me warnings about needing a
> format string for fprintf, but that is because the format string used has no
> '%' specifiers (I assume that is the reason it doesn't like the format
> string) and about ignoring function return values. I was going to fix those
> but decided to leave as is. Other than the warning messages, the compilation
> gives no errors.

If you want advice on those, you should show the exact message and the
code...

Nope only included since I thought it might be relevant to let you know that there were no errors, just warnings.

Marc Glisse-6 wrote:

> The relevant make file line is:
>
> $(CC) -o $@ -ldl -rdynamic $(OBJS)

If A depends on B, put A before B on the line (A is $(OBJS) and B is
-ldl).

> I created links in /lib as:

Never do that!

--
Marc Glisse

Okay that fixed the problem. Also, I deleted the links.

Curious that the makefile worked for the previous years (at least 10) with no problem. Maybe the latest  'make' is more strict regarding interpreting the rules ??

Thank you very much for fixing that for me. I would never have thought the makefile to be the problem after using it with no problem and no changes for so many years.

[Ian Lance Taylor-3]

geezers <fastsnip-gcc@...> writes:

> Curious that the makefile worked for the previous years (at least 10) with
> no problem. Maybe the latest  'make' is more strict regarding interpreting
> the rules ??

It doesn't have anything to do with make.  Something changed in your
libc.

Ian

[geezers]

Ian Lance Taylor-3 wrote:

geezers <[e-mail]> writes:

> Curious that the makefile worked for the previous years (at least 10) with
> no problem. Maybe the latest  'make' is more strict regarding interpreting
> the rules ??

It doesn't have anything to do with make.  Something changed in your
libc.

Ian

Then I do not understand. If I run the makefile as:

$(CC) -o $@ $(OBJS) -ldl -rdynamic

I get the error messages that the external references for dlopen, dlclose, etc cannot be satisfied.

If I change the makefile line to read:

$(CC) -o $@ -rdynamic $(OBJS) -ldl

the error messages do not appear and the executable is linked and runs properly.

Now it is possible it is in the libc and changing the makefile line makes the linker work with the new libc.

Is there a means of testing this and determining what changed in libc if that is the root cause of the problem.

[Ian Lance Taylor-3]

geezers <fastsnip-gcc@...> writes:

> Ian Lance Taylor-3 wrote:
>>
>> geezers <fastsnip-gcc@...> writes:
>>
>>> Curious that the makefile worked for the previous years (at least 10)
>>> with
>>> no problem. Maybe the latest  'make' is more strict regarding
>>> interpreting
>>> the rules ??
>>
>> It doesn't have anything to do with make.  Something changed in your
>> libc.
>>
>> Ian
>>
> Then I do not understand. If I run the makefile as:
>
> $(CC) -o $@ $(OBJS) -ldl -rdynamic
>
> I get the error messages that the external references for dlopen, dlclose,
> etc cannot be satisfied.
>
> If I change the makefile line to read:
>
> $(CC) -o $@ -rdynamic $(OBJS) -ldl
>
> the error messages do not appear and the executable is linked and runs
> properly.
>
> Now it is possible it is in the libc and changing the makefile line makes
> the linker work with the new libc.
>
> Is there a means of testing this and determining what changed in libc if
> that is the root cause of the problem.

You are saying that just moving the -rdynamic line changes the
behaviour?  That seems very strange.  The first step would be to take
make out of the equation and just run the commands directly from the
command line.  If you can repeat the problem that way, add the -v option
and look at the way the linker is being invoked.  Send the linker
commands back to this mailing list so that we can see why the different
linker command is causing the error.

Ian

[geezers]

Ian Lance Taylor-3 wrote:

geezers <[e-mail]> writes:

> Ian Lance Taylor-3 wrote:
>>
>> geezers <[e-mail]> writes:
>>
>>> Curious that the makefile worked for the previous years (at least 10)
>>> with
>>> no problem. Maybe the latest  'make' is more strict regarding
>>> interpreting
>>> the rules ??
>>
>> It doesn't have anything to do with make.  Something changed in your
>> libc.
>>
>> Ian
>>
> Then I do not understand. If I run the makefile as:
>
> $(CC) -o $@ $(OBJS) -ldl -rdynamic
>
> I get the error messages that the external references for dlopen, dlclose,
> etc cannot be satisfied.
>
> If I change the makefile line to read:
>
> $(CC) -o $@ -rdynamic $(OBJS) -ldl
>
> the error messages do not appear and the executable is linked and runs
> properly.
>
> Now it is possible it is in the libc and changing the makefile line makes
> the linker work with the new libc.
>
> Is there a means of testing this and determining what changed in libc if
> that is the root cause of the problem.


You are saying that just moving the -rdynamic line changes the
behaviour?  That seems very strange.  The first step would be to take
make out of the equation and just run the commands directly from the
command line.  If you can repeat the problem that way, add the -v option
and look at the way the linker is being invoked.  Send the linker
commands back to this mailing list so that we can see why the different
linker command is causing the error.

Ian

Sorry my mistake: The original makefile read:

$(CC) -o $@ -ldl -rdynamic $(OBJS)

and that was changed to read:

$(CC) -o $@ -rdynamic $(OBJS) -ldl

if I run the makefile as: $(CC) -v -o $@ -ldl -rdynamic $(OBJS)
I get:
linking                                                                        
gcc -v -o qtgrep.bin -ldl -rdynamic buffer.o displayu.o findfile.o getopt.o grepdfa.o date.o re_compile.o re_exec.o re_read.o re_write.o kw_compile.o kw_exec.o kw_read.o kw_write.o scan.o set_expr.o read_pat_file.o free_pat.o write_pat_file.o memory_fun.o                                                                
Using built-in specs.                                                          
COLLECT_GCC=gcc                                                                
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper              
Target: x86_64-linux-gnu                                                        
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'qtgrep.bin' '-rdynamic' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.6/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o qtgrep.bin /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. -ldl buffer.o displayu.o findfile.o getopt.o grepdfa.o date.o re_compile.o re_exec.o re_read.o re_write.o kw_compile.o kw_exec.o kw_read.o kw_write.o scan.o set_expr.o read_pat_file.o free_pat.o write_pat_file.o memory_fun.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o
set_expr.o: In function `QTGrep_load_compiled_searches':
/home/terry/Source/QTGrep_Multiple/set_expr.c:2036: undefined reference to `dlclose'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2042: undefined reference to `dlerror'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2045: undefined reference to `dlopen'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2047: undefined reference to `dlerror'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2052: undefined reference to `dlsym'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2053: undefined reference to `dlerror'
/home/terry/Source/QTGrep_Multiple/set_expr.c:2067: undefined reference to `dlerror'
collect2: ld returned 1 exit status
make: *** [qtgrep.bin] Error 1

If I run as: $(CC) -o $@ -rdynamic $(OBJS) -ldl
I get:

 make
linking
gcc -v -o qtgrep.bin -rdynamic buffer.o displayu.o findfile.o getopt.o grepdfa.o date.o re_compile.o re_exec.o re_read.o re_write.o kw_compile.o kw_exec.o kw_read.o kw_write.o scan.o set_expr.o read_pat_file.o free_pat.o write_pat_file.o memory_fun.o -ldl
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'qtgrep.bin' '-rdynamic' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.6/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o qtgrep.bin /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. buffer.o displayu.o findfile.o getopt.o grepdfa.o date.o re_compile.o re_exec.o re_read.o re_write.o kw_compile.o kw_exec.o kw_read.o kw_write.o scan.o set_expr.o read_pat_file.o free_pat.o write_pat_file.o memory_fun.o -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.6/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o

In looking through the 2 outputs quickly, I'm not too sure what I'm seeing. But then I don't really know what specifically to look for.

[Ian Lance Taylor-3]

geezers <fastsnip-gcc@...> writes:

> Sorry my mistake: The original makefile read:
>
> $(CC) -o $@ -ldl -rdynamic $(OBJS)
>
> and that was changed to read:
>
> $(CC) -o $@ -rdynamic $(OBJS) -ldl

OK, that makes me more sense.  It is always correct to put the -l option
after the objects that refer to it, and never correct to put the -l
option first.  The relative order of -l options and object files
matters.  Putting -ldl before the object files was probably working for
you only by accident.

Ian