[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