[cmake-developers] [CMake 0013352]: Incorrect linking of shared-library dependencies on AIX
Mantis Bug Tracker
mantis at public.kitware.com
Tue Jun 26 14:52:37 EDT 2012
The following issue has been SUBMITTED.
======================================================================
http://public.kitware.com/Bug/view.php?id=13352
======================================================================
Reported By: Daniel R. Gomez
Assigned To:
======================================================================
Project: CMake
Issue ID: 13352
Category: CMake
Reproducibility: always
Severity: major
Priority: normal
Status: new
======================================================================
Date Submitted: 2012-06-26 14:52 EDT
Last Modified: 2012-06-26 14:52 EDT
======================================================================
Summary: Incorrect linking of shared-library dependencies on
AIX
Description:
This report is borne of this failing dashboard test:
http://open.cdash.org/testDetails.php?test=150972101&build=2394658
Some tinkering around in the test directory:
cport at vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig>
env OBJECT_MODE=32 /usr/bin/gcc -mminimal-toc -O0
CMakeFiles/perconfig.dir/perconfig.c.o -o ../bin/perconfig ../bin/libpcStatic.a
../bin/libpcShared.so
-Wl,-blibpath:/home/cport/Dashboards/MyTests/CMake-build/Tests/CustomCommand/bin:/usr/lib:/lib
cport at vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig>
ldd ../bin/perconfig
../bin/perconfig needs:
/usr/lib/libc.a(shr.o)
../bin/libpcShared.so
/unix
/usr/lib/libcrypt.a(shr.o)
cport at vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig>
ln -s ../bin/libpcShared.so .
cport at vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig>
env OBJECT_MODE=32 /usr/bin/gcc -mminimal-toc -O0
CMakeFiles/perconfig.dir/perconfig.c.o -o ../bin/perconfig ../bin/libpcStatic.a
libpcShared.so
-Wl,-blibpath:/home/cport/Dashboards/MyTests/CMake-build/Tests/CustomCommand/bin:/usr/lib:/lib
cport at vibraslap:~/Dashboards/MyTests/CMake-build/Tests/CustomCommand/PerConfig>
ldd ../bin/perconfig
../bin/perconfig needs:
/usr/lib/libc.a(shr.o)
/home/cport/Dashboards/MyTests/CMake-build/Tests/CustomCommand/bin/libpcShared.so
/unix
/usr/lib/libcrypt.a(shr.o)
Notice how when the linker is given "../bin/libpcShared.so", it records exactly
that in the executable's dependencies, and fails to find the library dependency.
Only if I link in "libpcShared.so", without a path prefix, does the executable
build correctly.
Looking through the ld(1) man page, these bits appear relevant:
Note: If you specify a shared object, or an archive file containing a
shared object, with an absolute or relative path name, instead of with
the -lName flag, the path name is included in the import file ID string
in the loader section of the output file. You can override this
behavior with the -bnoipath option.
[...]
noipath
For shared objects listed on the command-line, rather than
specified with the -l flag, use a null path component when listing
the shared object in the loader section of the output file. A null
path component is always used for shared objects specified with
the -l flag. This option does not affect the specification of a
path component by using a line beginning with #! in an import
file. The default is the ipath option.
Adding -Wl,-bnoipath allows the original link invocation to produce a correct
binary.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2012-06-26 14:52 Daniel R. GomezNew Issue
======================================================================
More information about the cmake-developers
mailing list