Is there a way to print a list the filenames for the libraries linked into a target via the target_link_libraries command
or even better, have all a target's dependencies copied to a specific folder?
get_target_property(OUT Target LINK_LIBRARIES)
message(STATUS ${OUT})
I realise this doesn't fully answer the question with regards doing it within cmake, but I faced a similar problem and thought I should share my solution.
First, in your source directory ("project"):
$ mkdir build && cd build
$ cmake ..
Then, use graphviz to create a dot file, as in this answer:
$ cmake --graphviz=graph.dot .
Then, strip out the dependencies from the graph for your target (let's call it "foo"):
$ sed -n 's/.*label="\(.*\)"\s.*/\1/p' graph.dot.foo > foo_dependencies.txt
Now, remove the clutter:
$ rm graph.dot*
Actually not(*).
However, you can use a cmake variable to collect the name of the libraries that you want to link (using the set( ... or the list(APPEND ... command), and then use this variable in your target_link_libraries command:
target_link_libraries(<targetname> ${YOUR_CMAKE_VARIABLE})
The same variable can also be used to create your copy commands (for example using this custom target)
(*) A similar question was asked here, and it got no definitive answer.
Well, all linked libraries to a given target TARGET are in the build.../CMakeFiles/TARGET.dir/link.txt.
For instance, TARGET=dirac.x,
.../build_intel17_mkl_i8/.less CMakeFiles/dirac.x.dir/link.txt
There will be a large number of linked libraries:
/cvmfs/it.gsi.de/compiler/intel/17.0/compilers_and_libraries_2017.4.196/linux/bin/intel64/ifort -Wl,-E -w -assume byterecl -g -traceback -DVAR_IFORT -i8 -w -assume byterecl -g -traceback -DVAR_IFORT -i8 -O3 -ip CMakeFiles/dirac.x.dir/src/main/main.F90.o -o dirac.x -L/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/lib -L/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/gen1int-build/external/lib -L/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/pelib-build/external/lib -Wl,-rpath,/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/lib:/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/gen1int-build/external/lib:/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/pelib-build/external/lib: libobjlib.dirac.x.a src/pelib/libpelib_interface.a external/lib/libstieltjes.a -limf -lsvml -lirng -lstdc++ -lm -lipgo -ldecimal -lstdc++ -lgcc -lgcc_s -lirc -lsvml -lc -lgcc -lgcc_s -lirc_s -ldl -lc external/pcmsolver/install/lib/libpcm.a /usr/lib/x86_64-linux-gnu/libz.so -limf -lsvml -lirng -lstdc++ -lm -lipgo -ldecimal -lstdc++ -lgcc -lgcc_s -lirc -lsvml -lc -lgcc -lgcc_s -lirc_s -ldl -lc /usr/lib/x86_64-linux-gnu/libz.so src/libxcfun_fortran_bindings.a external/xcfun-build/src/libxcfun.a external/lib/libpelib.a libgen1int_interface.a external/lib/libgen1int.a -Wl,--start-group /cvmfs/it.gsi.de/compiler/intel/17.0/compilers_and_libraries_2017.4.196/linux/mkl/lib/intel64/libmkl_lapack95_ilp64.a -lmkl_intel_ilp64 -qopenmp -Wl,--end-group -Wl,--start-group -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_core -lpthread /usr/lib/x86_64-linux-gnu/libm.so -qopenmp -Wl,--end-group external/pcmsolver/install/lib/libpcm.a external/xcfun-build/src/libxcfun.a external/lib/libpelib.a external/lib/libgen1int.a /cvmfs/it.gsi.de/compiler/intel/17.0/compilers_and_libraries_2017.4.196/linux/mkl/lib/intel64/libmkl_lapack95_ilp64.a -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_core -lpthread /usr/lib/x86_64-linux-gnu/libm.so -lirng -ldecimal -lstdc++
Related
I'm using a third party project that provides dependencies to link against via a pkg-config file, which I pass to my target via target_link_libraries. The final result looks something like this example:
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(main)
add_executable(main main.c)
target_link_libraries(
main
PRIVATE -lfoo
-Wl,--whole-archive
-lbar
-Wl,--no-whole-archive
-lfoo
-Wl,-Bdynamic
-lbaz)
Where main.c is a trivial C source file:
$ cat main.c
int main() { return 0; }
When I run CMake's configure step and inspect the generated compile commands, I see some libraries duplicated across link flags:
$ cmake -S . -B build -GNinja
$ ninja -C build -t commands
/usr/bin/cc -MD -MT CMakeFiles/main.dir/main.c.o -MF CMakeFiles/main.dir/main.c.o.d -o CMakeFiles/main.dir/main.c.o -c /home/ja/toy/main.c
: && /usr/bin/cc CMakeFiles/main.dir/main.c.o -o main -lfoo -Wl,--whole-archive -lbar -Wl,--no-whole-archive -lfoo -Wl,-Bdynamic -lbaz -lbar -lbaz && :
Clearly, -lbar was repeated across --no-whole-archive and -Bdynamic. Is this equivalent to the original target_link_libraries call? Why does CMake do this?
Additionally, I tried experimenting without the link flags, and noticed that CMake transforms -lfoo -lbar -lfoo -lbaz into -lfoo -lbar -lfoo -lbaz -lbar -lbaz. I suspect it might have something to do with the behavior described at LINK_INTERFACE_MULTIPLICITY but I do not understand the rationale behind doing this across link flags.
Edit: I'm using CMake version 3.23.0.
I run some command before the actual build
add_custom_target("${PROJECT_BUILD_NUM_FILE}"
COMMAND ${PROJECT_BUILD_NUM_UPDATE} "-p" "-x" -f ${PROJECT_SOURCE_DIR}/${MAIN_PATH}/${BOARD_NAME}/${PROJECT_BUILD_NUM_FILE}
)
add_dependencies(${EXECUTABLE_NAME} "${PROJECT_BUILD_NUM_FILE}" )
When I build first time (the project was build before)
>------ Build started: Project: CMakeLists, Configuration: Debug ------
[1/1] cmd.exe /C "cd /D C:\Users\Piotr\git\gPIMS-EG\out\build\IoT-Debug && C:\Users\Piotr\git\gPIMS-EG\stm-libs\pc-exe\buildnum.exe -p -x -f C:/Users/Piotr/git/gPIMS-EG/src/EG/BuildID.h"
Build number file used:C:/Users/Piotr/git/gPIMS-EG/src/EG/BuildID.h
Build file updated: Build Number: 22 DateCode: 0x1d6d
Build succeeded.
BuildID.h file was modified and saved. Modification date is set correctly.
On the second build it behaves correctly
>------ Build started: Project: CMakeLists, Configuration: Debug ------
[1/4] cmd.exe /C "cd /D C:\Users\Piotr\git\gPIMS-EG\out\build\IoT-Debug && C:\Users\Piotr\git\gPIMS-EG\stm-libs\pc-exe\buildnum.exe -p -x -f C:/Users/Piotr/git/gPIMS-EG/src/EG/BuildID.h"
Build number file used:C:/Users/Piotr/git/gPIMS-EG/src/EG/BuildID.h
Build file updated: Build Number: 23 DateCode: 0x1d6d
[2/4] C:\PROGRA~2\Atollic\TRUEST~1.0\ARMTools\bin\AR097D~1.EXE -DALLOW_SOFTWARE_BKPTS=1 -DARM_MATH_CM4 -DBOOTLOADER_VERSION=1 -DCOMPILE_FOR_EG=1 -DDEBUGFILEWRITE=1 -DDEBUG_RUN_WITHOUT_CHECKS=1 -DFORCE_CUBE_USB -DHSE_VALUE=8000000UL -DSLOWSPIDEBUG=0 -DSTM32L -DSTM32L476xx -DSTM32L4xx -DUSE_EMBEDDED_PHY=1 -DUSE_FULL_ASSERT -DUSE_FULL_LL_DRIVER="" -DUSE_HAL_DRIVER -DUSE_SWOTRACE=1 -DUSE_USB_OTG_FS=1 -DUSE_USB_OTG_HS=1 -D_DEBUG=1 -D_GNU_SOURCE=1 -D__USE_SIMPLE_SWO=0 -I../../../src -I../../../src/EG -I../../../src/ZM -I../../../src/inc -I../../../stm-libs/inc -I../../../stm-libs/Drivers -I../../../stm-libs/Services -I../../../stm-libs/Services/Utils -I../../../stm-libs/RTOS/Source/include -I../../../stm-libs/RTOS/Source/portable/GCC/ARM_CM4F -I../../../stm-libs/Libraries/CMSIS/Include -I../../../stm-libs/Libraries/CMSIS/Device/ST/STM32L4xx/Include -I../../../stm-libs/Libraries/CryptoLib/Inc -I../../../stm-libs/Libraries/CryptoLib/Inc/RNG -I../../../stm-libs/drivers/USBD -I../../../stm-libs/Libraries/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I../../../stm-libs/Libraries/USB/Device/Class/CDC/Inc -I../../../stm-libs/Libraries/USB/Device/Class/MSC_HID/Inc -I../../../stm-libs/Libraries/USB/Device/Core/Inc -I../../../stm-libs/Libraries/lwip/ports/STM32F4x7 -I../../../stm-libs/Libraries/lwip/ports/STM32F4x7/arch -I../../../stm-libs/Libraries/lwip/src -I../../../stm-libs/Libraries/lwip/src/include -I../../../stm-libs/drivers/USBH -I../../../stm-libs/Libraries/USB/Host/Class/AUDIO/Inc -I../../../stm-libs/Libraries/USB/Host/Class/CDC/Inc -I../../../stm-libs/Libraries/USB/Host/Class/HID/Inc -I../../../stm-libs/Libraries/USB/Host/Class/MSC/Inc -I../../../stm-libs/Libraries/USB/Host/Class/MTP/Inc -I../../../stm-libs/Libraries/USB/Host/Core/Inc -I../../../stm-libs/Libraries/USB/Host/Class/Template/Inc -I../../../stm-libs/Libraries/lwip/ports/STM32F4x7/FreeRTOS -I../../../stm-libs/Libraries/misc -I../../../stm-libs/Libraries/FatFs/src -I../../../stm-libs/Libraries/littleFS -I../../../stm-libs/Apps -I../../../stm-libsApps/SeqZM -I../../../stm-libs/Libraries/libc_e -I../../../stm-libs/Libraries -I../../../stm-hal-l4/Inc/Legacy -I../../../stm-hal-l4/Inc -I../../../stm-libs/Apps/Other -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Og -g3 -T"C:/Users/Piotr/git/gPIMS-EG/src/EG/startup/EG.ld" -L"C:/Users/Piotr/git/gPIMS-EG/stm-libs/Libraries/CryptoLib" -lSTM32CryptographicV3.0.0_CM4_GCC_FPU -specs=nosys.specs -specs=nano.specs -Wl,-Map="EG.map" -static -Wl,-u,Reset_Handler -Wl,--gc-sections -Wl,--defsym=malloc_getpagesize_P=0x80 -Wl,--start-group -lc -lm -Wl,--end-group -ffunction-sections -fdata-sections -g -MD -MT CMakeFiles/GCEG-FW.dir/stm-libs/Apps/common/SC_Ver.c.obj -MF CMakeFiles\GCEG-FW.dir\stm-libs\Apps\common\SC_Ver.c.obj.d -o CMakeFiles/GCEG-FW.dir/stm-libs/Apps/common/SC_Ver.c.obj -c ../../../stm-libs/Apps/common/SC_Ver.c
In file included from ../../../stm-libs/Apps/common/SC_Ver.c:9:0:
C:\Users\Piotr\git\gPIMS-EG\stm-libs\Drivers\CAN-COB.h(267,2): warning GF07C7A44: #warning added to compile BP to change [-Wcpp]
#warning added to compile BP to change
^~~~~~~
[3/4] C:\PROGRA~2\Atollic\TRUEST~1.0\ARMTools\bin\AR097D~1.EXE -DALLOW_SOFTWARE_BKPTS=1 -DARM_MATH_CM4 -DBOOTLOADER_VERSION=1 -DCOMPILE_FOR_EG=1 -DDEBUGFILEWRITE=1 -DDEBUG_RUN_WITHOUT_CHECKS=1 -DFORCE_CUBE_USB -DHSE_VALUE=8000000UL -DSLOWSPIDEBUG=0 -DSTM32L -DSTM32L476xx -DSTM32L4xx -DUSE_EMBEDDED_PHY=1 -DUSE_FULL_ASSERT -DUSE_FULL_LL_DRIVER="" -DUSE_HAL_DRIVER -DUSE_SWOTRACE=1 -DUSE_USB_OTG_FS=1 -DUSE_USB_OTG_HS=1 -D_DEBUG=1 -D_GNU_SOURCE=1 -D__USE_SIMPLE_SWO=0 -I../../../src -I../../../src/EG -I../../../src/ZM -I../../../src/inc -I../../../stm-libs/inc -I../../../stm-libs/Drivers -I../../../stm-libs/Services -I../../../stm-libs/Services/Utils -I../../../stm-libs/RTOS/Source/include -I../../../stm-libs/RTOS/Source/portable/GCC/ARM_CM4F -I../../../stm-libs/Libraries/CMSIS/Include -I../../../stm-libs/Libraries/CMSIS/Device/ST/STM32L4xx/Include -I../../../stm-libs/Libraries/CryptoLib/Inc -I../../../stm-libs/Libraries/CryptoLib/Inc/RNG -I../../../stm-libs/drivers/USBD -I../../../stm-libs/Libraries/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I../../../stm-libs/Libraries/USB/Device/Class/CDC/Inc -I../../../stm-libs/Libraries/USB/Device/Class/MSC_HID/Inc -I../../../stm-libs/Libraries/USB/Device/Core/Inc -I../../../stm-libs/Libraries/lwip/ports/STM32F4x7 -I../../../stm-libs/Libraries/lwip/ports/STM32F4x7/arch -I../../../stm-libs/Libraries/lwip/src -I../../../stm-libs/Libraries/lwip/src/include -I../../../stm-libs/drivers/USBH -I../../../stm-libs/Libraries/USB/Host/Class/AUDIO/Inc -I../../../stm-libs/Libraries/USB/Host/Class/CDC/Inc -I../../../stm-libs/Libraries/USB/Host/Class/HID/Inc -I../../../stm-libs/Libraries/USB/Host/Class/MSC/Inc -I../../../stm-libs/Libraries/USB/Host/Class/MTP/Inc -I../../../stm-libs/Libraries/USB/Host/Core/Inc -I../../../stm-libs/Libraries/USB/Host/Class/Template/Inc -I../../../stm-libs/Libraries/lwip/ports/STM32F4x7/FreeRTOS -I../../../stm-libs/Libraries/misc -I../../../stm-libs/Libraries/FatFs/src -I../../../stm-libs/Libraries/littleFS -I../../../stm-libs/Apps -I../../../stm-libsApps/SeqZM -I../../../stm-libs/Libraries/libc_e -I../../../stm-libs/Libraries -I../../../stm-hal-l4/Inc/Legacy -I../../../stm-hal-l4/Inc -I../../../stm-libs/Apps/Other -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Og -g3 -T"C:/Users/Piotr/git/gPIMS-EG/src/EG/startup/EG.ld" -L"C:/Users/Piotr/git/gPIMS-EG/stm-libs/Libraries/CryptoLib" -lSTM32CryptographicV3.0.0_CM4_GCC_FPU -specs=nosys.specs -specs=nano.specs -Wl,-Map="EG.map" -static -Wl,-u,Reset_Handler -Wl,--gc-sections -Wl,--defsym=malloc_getpagesize_P=0x80 -Wl,--start-group -lc -lm -Wl,--end-group -ffunction-sections -fdata-sections -g -MD -MT CMakeFiles/GCEG-FW.dir/stm-libs/Apps/WaveMC3/waveMC3SeqGUI.c.obj -MF CMakeFiles\GCEG-FW.dir\stm-libs\Apps\WaveMC3\waveMC3SeqGUI.c.obj.d -o CMakeFiles/GCEG-FW.dir/stm-libs/Apps/WaveMC3/waveMC3SeqGUI.c.obj -c ../../../stm-libs/Apps/WaveMC3/waveMC3SeqGUI.c
In file included from ../../../stm-libs/Drivers/CAN-G3M.h:31:0,
from ../../../stm-libs/Drivers/ioCmd.h:12,
from ../../../stm-libs/Services/srvCmd.h:9,
from ../../../src/EG/../ZM/zmServices.h:10,
from ../../../src/EG/ourServices.h:12,
from ../../../stm-libs/Apps/WaveMC3/waveMC3SeqGUI.c:5:
C:\Users\Piotr\git\gPIMS-EG\stm-libs\Drivers\CAN-COB.h(267,2): warning GF07C7A44: #warning added to compile BP to change [-Wcpp]
#warning added to compile BP to change
^~~~~~~
[4/4] cmd.exe /C "cd . && C:\PROGRA~2\Atollic\TRUEST~1.0\ARMTools\bin\AR097D~1.EXE -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Og -g3 -T"C:/Users/Piotr/git/gPIMS-EG/src/EG/startup/EG.ld" -L"C:/Users/Piotr/git/gPIMS-EG/stm-libs/Libraries/CryptoLib" -lSTM32CryptographicV3.0.0_CM4_GCC_FPU -specs=nosys.specs -specs=nano.specs -Wl,-Map="EG.map" -static -Wl,-u,Reset_Handler -Wl,--gc-sections -Wl,--defsym=malloc_getpagesize_P=0x80 -Wl,--start-group -lc -lm -Wl,--end-group -ffunction-sections -fdata-sections -g #CMakeFiles\GCEG-FW.rsp -o GCEG-FW.elf && cmd.exe /C "cd /D C:\Users\Piotr\git\gPIMS-EG\out\build\IoT-Debug && "C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\ARMTools\bin\arm-atollic-eabi-objcopy.exe" GCEG-FW.elf --output-target=binary GCEG-FW.bin -j .isr_vector -j .VERSION_INFO -j .text -j .rodata -j .ARM.extab -j .ARM -j .preinit_array -j .init_array -j .fini_array -j .data -j .RAM_VectorTable -j .RAM_DATAfunctions -j .RAM_functions -v && "C:\Program Files (x86)\Atollic\TrueSTUDIO for STM32 9.3.0\ARMTools\bin\arm-atollic-eabi-size.exe" GCEG-FW.elf --format=Berkeley""
copy from `GCEG-FW.elf' [elf32-littlearm] to `GCEG-FW.bin' [binary]
text data bss dec hex filename
210428 36680 54020 301128 49848 GCEG-FW.elf
Build succeeded.
It looks like ninja is checking dependencies before the actual build starts and ignores meanwhile file changed. Is there any way to force cmake/ninja to recheck dependecies after custom target is build (ie prgram that thenges the build is run).
It looks like ninja is checking dependencies before the actual build starts and ignores meanwhile file change
Hey! Yes. Because DEPFILEs from C source files are generated at the same time as they are compiled, cmake has no way to know beforehand which file depends on which. It would have to do two passes - first to get dependencies and then to compile (which would be a nice feature, but actually hard to implement). It happens in one pass during compilation (-MD -MT flags), so cmake has no way of knowing that one file depends on that header. I also advise:
Do not modify files in your source tree. Keep all changes in BINARY_DIR.
Do not modify files. Generate new files. It's easier and generally, less state = less problems.
Try it such:
# Inside binary_dir
set(PROJECT_BUILD_NUM_FILE ${CMAKE_CURRENT_BINARY_DIR}/gen/buildid_gen.h)
# Add #include <buildid_gen.h> to your buildid.h
add_custom_command(
OUTPUT ${PROJECT_BUILD_NUM_FILE}
COMMAND ${PROJECT_BUILD_NUM_UPDATE} "-p" "-x" -f ${PROJECT_BUILD_NUM_FILE}
DEPENDS ${PROJECT_BUILD_NUM_UPDATE}
)
add_custom_target(buildid_gen
COMMENT "Yooohooo!"
DEPENDS ${PROJECT_BUILD_NUM_FILE}
)
add_executable(${EXECUTABLE_NAME} ${PROJECT_BUILD_NUM_FILE} ${some_other_sources})
target_add_include_directories(${EXECTABLE_NAME} PUBLIC
# add include directory, so that buildid_gen is found
${CMAKE_CURRENT_BINARY_DIR}/gen
)
# this *helps*
add_dependencies(${EXECUTABLE_NAME} buildid_gen)
Is there any way to force cmake/ninja to recheck dependecies after custom target is build (ie prgram that thenges the build is run).
The real proper way ™ would be to manually track all files that depend on the file (you could think of grep -l '#include <buildid_gen.h> to get the list files) and communicate to cmake the dependency relation:
add_source_file_properties(${sources_that_include_buildid_gen} PROPERTIES OBJECT_DEPENDS ${PROJECT_BUILD_NUM_FILE})
Tracking dependencies is easier if you use a runtime interface (ie. long get_build_id();) cause then only one .c file that implements the interface will depend on the generated file.
There are also some projects that are compiled in two passes because of such dependencies, you have to first cmake .. --target buildid_gen and then cmake .. --target actually_compile each time you compile.
Also maybe execute_process is more appropriate if the file is setup once per build.
I'm building a shared library and an application using that lib on Cygwin. With GCC CMake creates a .dll.a to use when linking. Switching to clang I get
[ 34%] Built target xxx_shared
make[2]: *** No rule to make target 'src/libxxx.dll.a', needed by 'xxx.exe'. Stop.
Is this a bug in the clang CMake extension?
I'm using cmake --version 3.3.2
Yes, it seems to be a bug in CMake. Running make VERBOSE=1 reveals that with GCC:
/usr/bin/c++.exe -g -shared -Wl,--enable-auto-import -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
while with clang:
/usr/bin/clang++ -fPIC -g -shared -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
So it seems that somehow clang++ does not get the -Wl,--enable-auto-import flag. Manually running the corrected clang++ command correctly creates the expected .dll.a allowing the rest of the build to proceed as expected.
Haven't figured out why this happens yet, though. At this point I can't decipher CMakes platform extensions, which seems to set this for GCC.
Update: I've reported this here.
The correct link command is
g++ file1.o file2.o xxx.0 -o target -I./ -I/usr/local/libmylibone/
-L./ -L/usr/local/testlib/ ../lib/special_lib/static_lib.a
-lasn1c++ -lmysqlclient -lnsl -lm -lz -lc -ldl -lpthread -lrt -ljson
Please focus on ../lib/special_lib/static_lib.a, this is a static library and not named with libxxx.a. And I don't know how to write a CMake command to get this correct link command.
I've tried TARGET_LINK_LIBRARIES(../lib/special_lib/static_lib.a) and it will be translated to -l../lib/special_lib/static_lib.a. I've also tried TARGET_LINK_LIBRARIES(static_lib) but got -lstatic_lib and failed.
If you put the absolute path to your library it should work:
TARGET_LINK_LIBRARIES(your_binary /usr/local/lib/static_lib.a)
Second option:
ADD_LIBRARY(staticlib STATIC IMPORTED)
SET_TARGET_PROPERTIES(staticlib PROPERTIES IMPORTED_LOCATION /usr/local/lib/static_lib.a)
TARGET_LINK_LIBRARIES(your_binary staticlib)
The official CMake documentation for importing/exporting targets is here.
I have a GNU build system with autoconf-2.69, automake-1.14.1, libtool-2.4.2. I've configured with --host=i686-linux on a x86_64 RHEL6 host OS to build a 32-bit program. The libtool command seems to be:
/bin/sh ../libtool --tag=CXX --mode=link g++ -I/home/STools/RLX/boost/include/boost-1_44 -m32 -g3 -Wall -static -o engine engine-main.o ../components/librlxvm.la /home/STools/RLX/boost/include/boost-1_44/../../lib/libboost_program_options-gcc42-mt-1_44.a -lz -lpthread -ldl -lrt -ldl -lz -lm
But the real command is to search the 64-bit libraries not the 32-bit libraries as shown below:
libtool: link: g++ -I/home/STools/RLX/boost/include/boost-1_44 -m32 -g3 -Wall -o engine engine-main.o -L/home/robert_bu/src/gcc/gcc-4.2.2/build-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/robert_bu/src/gcc/gcc-4.2.2/build-x86_64/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/robert_bu/src/gcc/gcc-4.2.2/build-x86_64/./gcc ../components/.libs/librlxvm.a /home/STools/RLX/boost/include/boost-1_44/../../lib/libboost_program_options-gcc42-mt-1_44.a /home/STools/RLX/gcc-4.2.2-x86_64/lib/../lib64/libstdc++.so -L/lib/../lib64 -L/usr/lib/../lib64 -lc -lgcc_s -lrt -ldl -lz -lm -pthread -Wl,-rpath -Wl,/home/STools/RLX/gcc-4.2.2-x86_64/lib/../lib64 -Wl,-rpath -Wl,/home/STools/RLX/gcc-4.2.2-x86_64/lib/../lib64
The --host config seems to have no effect. Is there anyway to tell libtool that 32-bit libraries are what we want?
It seems that libtool uses "CC", "CXX" to check the library search path. After I set CC to "gcc -m32", and CXX to "g++ -m32", it works. So libtool does not add "-m32" automatically even if I try to build a 32-bit program on a 64-bit system.
You're being hit by the problem of libtool .la files expansion. In particular libstdc++.la is being expanded for you to a full path rather than a simple -lstdc++.
My suggestion is to remove .la file from the SDK you're using (/home/STools). This way libtool can't assume things for you. Usually the ones you have in the system are fine, because the libraries are already in the search path, so it does not need to use -rpath or the full path to the .so file.
Depending on how well the SDK was crafted, this might or might not work correctly, so take it with a grain of salt.