|
Notes |
|
|
(0020238)
|
|
Bill Hoffman
|
|
2010-04-17 12:28
|
|
Strange, we run a dashboard on one of those...
Can you remove one of the binaries, and do a make VERBOSE=1 and see what the link line looks like? |
|
|
|
(0020244)
|
|
Daniel Richard G.
|
|
2010-04-17 23:05
|
|
Way ahead of you.
Here is how the "cmake" binary is linked in bootstrapping:
tg-g++ -pipe -fmessage-length=0 -fno-for-scope -fno-rtti -W -Wall -Wcast-align -Wformat=2 -Wpointer-arith -Wundef -O3 -I/tmp/cmake-build/Bootstrap.cmk -I/tmp/cmake-2.8.1/Source -I/tmp/cmake-build/Bootstrap.cmk cmake.o cmakemain.o cmakewizard.o cmCommandArgumentLexer.o [lotsa object files] SystemTools.o ProcessUNIX.o String.o System.o -o cmake
And the link line when building normally, with VERBOSE=1:
/opt/tg/bin/tg-g++ -pipe -fmessage-length=0 -fno-for-scope -fno-rtti -W -Wall -Wcast-align -Wformat=2 -Wpointer-arith -Wundef -O3 CMakeFiles/cmake.dir/cmakemain.o -o ../bin/cmake -Wl,+s,-E,+nodefaultrpath libCMakeLib.a kwsys/libcmsys.a ../Utilities/cmexpat/libcmexpat.a ../Utilities/cmtar/libcmtar.a ../Utilities/cmcompress/libcmcompress.a ../Utilities/cmcurl/libcmcurl.a ../Utilities/cmzlib/libcmzlib.a -ldld
If I remove the +nodefaultrpath option, the resulting binary works. However, this is an option you want; from the ld(1) man page...
+[no]defaultrpath
+defaultrpath is the default. Include any paths
that are specified with -L in the embedded path,
unless you specify the +b option. If you use +b,
only the path list specified by +b is in the
embedded path.
The +nodefaultrpath option removes all library
paths that were specified with the -L option from
the embedded path. The linker searches the
library paths specified by the -L option at link
time. At run time, the only library paths
searched are those specified by the environment
variables LD_LIBRARY_PATH and SHLIB_PATH, library
paths specified by the +b linker option, and
finally the default library paths.
Now here's where things get a bit weird: If I perform the link manually with
-Wl,+s,-E,+nodefaultrpath
changed to
-Wl,+s,-E,+nodefaultrpath,+b,/usr/lib
(i.e. explicitly adding the default library path to the binary's rpath), then the resulting binary works. So it seems that this may be a bug in the linker, where +nodefaultrpath doesn't do the "finally the default library paths" bit as advertised.
$ ld -V
92453-07 linker command s800.sgs ld PA64 B.11.53 REL 060322
ld: 92453-07 linker linker ld B.11.53 060322
ld: Usage: ld [options] [flags] files
(One more thing... when linking normally, is the -ldld bit really necessary? I can drop it without consequence.) |
|
|
|
(0020249)
|
|
Brad King
|
|
2010-04-19 08:15
|
|
Something similar happens on AIX. Look at Modules/Platform/AIX.cmake:
# RPATH support on AIX is called libpath. By default the runtime
# libpath is paths specified by -L followed by /usr/lib and /lib. In
# order to prevent the -L paths from being used we must force use of
# -Wl,-blibpath:/usr/lib:/lib whether RPATH support is on or not.
# When our own RPATH is to be added it may be inserted before the
# "always" paths.
SET(CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH /usr/lib /lib)
Does adding a line like this to HP-UX.cmake help? |
|
|
|
(0020259)
|
|
Daniel Richard G.
|
|
2010-04-19 13:53
|
|
I added
SET(CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH /usr/lib)
to the top of Modules/Platform/HP-UX.cmake, and with that, the build completes successfully.
(/lib is, of course, just a symlink to /usr/lib on this system.) |
|
|
|
(0020356)
|
|
Daniel Richard G.
|
|
2010-04-22 13:56
|
|
|
The attached patch, against 2.8.1, fixes this bug. |
|
|
|
(0022103)
|
|
Magnus Sirviö
|
|
2010-09-07 08:12
|
|
We hit the same issue when building CMake 2.8.2 on an HP-UX 11i system.
# uname -a
HP-UX xxxxx B.11.11 U 9000/800 538706567 unlimited-user license
The attached patch solved the problem. |
|
|
|
(0022104)
|
|
Brad King
|
|
2010-09-07 08:50
|
|
|
cmake-10571-fix.patch (466) 2010-04-22 13:56