I am quite new to libtool and related input files of the same. I know that it uses configure.ac or configure.in file as input and generate necessary file. I would like to remove complete rpath in libraries that are generated post compilation. Observed that it uses "hardcode_into_libs" variable from generated "configure" file. Any idea how to set that variable to "no" via configure.in file or configure.ac files?
Thanks in advance
Related
How to specify an output file name dynamically via a command line for a library?
# something like this
cargo build --output-file-name "my_lib.so" # or .*dylib
Doing it via Cargo.toml or .cargo/config won't work for me.
Is it possible at all?
Edit:
See the following: https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target which might help you specify the name of the final .so
The following parameter controls the output file name in rustc
https://doc.rust-lang.org/rustc/command-line-arguments.html#-o-filename-of-the-output
As Steve Marnach mentioned you can pass flags to rustc through several ways described here.
Alternatively you could have a post-build script using Philipp Oppermann's cargo-post tool and set it up to rename the output lib.
I have a rather complex CMake configuration, which contains several execute_process commands which create files during the configuration stage. Sometimes after some changes in the CMake configuration the generation stage deletes these files. I can reproduce that.
I've checked that the files exist after the configuration stage but are gone after the Makefile generation and before actually calling make.
The files are created in some cases simply by ${CMAKE_COMMAND} -E copy and in other cases by calling a script with ${CMAKE_COMMAND} -P which contains a configure_file call to replace some placeholders in a template.
The files are created in the source tree. Their purpose is to provide the developer with some initial code. When the developer has edited the files, they should be committed to version control and not be re-created again unless they are missing. I have add_custom_commands to recreate the files if they're missing, but those are not the culprit.
I know, you'd prefer a simple test example, but unfortunately this is not so easy to create, so my question is:
What might be the cause and how can I debug that?
Unfortunately, the --trace options of cmake do not give any log data about the generation stage.
Versions
OS: Ubuntu 16.04
CMake 3.5.1 (belonging to Ubuntu 16.04)
Update
I've compiled CMake itself with the current master commit (696b2d4) and the behavior is still the same.
By running CMake under a debugger I've discovered that the line
cmSystemTools::RemoveFile(fname);
in function cmGlobalGenerator::CheckRuleHashes(std::string const& pfile, std::string const& home) actually deletes the files. It is called from cmGlobalGenerator::Generate().
With further debugging (see update in the question) I've found the cause of my problem.
CMake's behavior
CMake's global generator creates the file ${CMAKE_BINARY_DIR}/CMakeFiles/CMakeRuleHashes.txt. It contains a line for every custom command with outputs. Each line contains a hash and the path to the first output of the custom command.
The hash is made over the current binary dir of the custom command and the entire content of the COMMAND arguments of add_custom_command.
On generation CMake executes cmGlobalGenerator::CheckRuleHashes to check if the hashes are still up to date. If a hash is not up to date the corresponding output file will be removed, obviously to trigger re-execution of the custom command in the build stage.
Cause of my problem
As mentioned in the question I execute the file creation command with execute_process during configuration and call add_custom_command with the same file creation command to trigger re-creation of the file in case it was missing.
So, CMake creates a hash line in its CMakeRuleHashes.txt for the file to be created.
Some of my add_custom_command calls are contained in a CMake file included from different CMakeLists.txt belonging to different sub-directories of the source. Depending on my actual configuration only specific sub-directories are added with add_subdirectory.
Thus, because the sub-directory is part of the hash of the custom command, the hash changes depending on the sub-directory added which includes the custom command. The changed hash then causes the deletion of the output file.
Conclusion
I have to redesign my CMake configuration to resolve the dependency of the custom command on the CMake binary directory.
Debugging generation stage
This could be done by compiling CMake itself as Debug build type and run it under a debugger.
I have SCons code in which I am using SConscripts to build different directories separately. In my Src directory, my SConscript builds a shared library, and then returns the resulting Node as the Python variable libMyLibrary. I typically use the install option to copy this library to a directory that is on my system's LD_LIBRARY_PATH (I'm using OpenSUSE).
So far, so good. Now, in another directory, Src/Test, another SConscript imports libMyLibrary and builds some Programs using code like this:
env.Program('myProgram', 'myProgram.cpp', LIBS=[env['LIBS'], libMyLibrary])
The program then gets installed to my local bin folder. This code does track the library dependency and build the program, but the problem is that since the library is in a sub-directory (Src), that sub-directory gets included in the linker command. Here is an abbreviated example of the linker command that SCons generates:
g++ -o Src/Test/myProgram Src/Test/myProgram.o Src/libMyLibrary.so
I believe this happens because the Node,libMyLibrary, is essentially a path. The problem is that when I try to run the program, it is not looking for libMyLibrary.so in my library folder, but rather Src/libMyLibrary.so, and of course it doesn't find it.
I do NOT want the libraries I build to be installed in sub-directories of my install folder.
I already add the Src folder to LIBPATH, so SCons adds the -LSrc option to the linker command, but that doesn't solve the problem. My preference would be that when I add a Node, the path should automatically get parsed out to add the appropriate -L and -l options.
I know that I can get around this problem by adding the string 'MyLibrary' to the LIBS variable instead of the libMyLibrary Node, but then I have to explicitly tell SCons that each Program Depends() on libMyLibrary. It seems very inefficient to short-circuit SCons's built-in dependency tracking this way. Does anyone know the correct, SCons-y way to do this?
I'm referring to your latest comment: It looks to me as if this is not really a SCons problem, but more a general linker question (XY problem). Are you perhaps simply searching for RPATH? Please also check this old SO question: scons executable + shared library in project directory
This is the way I install the config files:
file(GLOB ConfigFiles ${CMAKE_CURRENT_SOURCE_DIR}/configs/*.xml
${CMAKE_CURRENT_SOURCE_DIR}/configs/*.xsd
${CMAKE_CURRENT_SOURCE_DIR}/configs/*.conf)
install(FILES ${ConfigFiles} DESTINATION ${INSTDIR})
But I need to convert one of the xml files before installing it. There is an executable that can do this job for me:
./Convertor a.xml a-converted.xml
How can I automatically convert the xml file before installing it? It should be a custom command or target that installing depends on it, I just don't know how to make the install command depend on it though. Any advice would be appreciated!
Take a look at the SCRIPT version of install:
The SCRIPT and CODE signature:
install([[SCRIPT <file>] [CODE <code>]] [...])
The SCRIPT form will invoke the given CMake script files during
installation. If the script file name is a relative path it will be
interpreted with respect to the current source directory. The CODE
form will invoke the given CMake code during installation. Code is
specified as a single argument inside a double-quoted string.
For example:
install(CODE "execute_process(\"./Convertor a.xml a-converted.xml\")")
install(FILES a-converted.xml DESTINATION ${INSTDIR})
Be sure to checkout the entry for execute_process in the manual. Also be aware that macro expansion inside the CODE parameter can be a bit tricky to get right. Check the generated cmake_install.cmake in your build directory where the generated code will be placed.
I think that your specific case would work better if you were to use a custom command and target like so:
add_custom_command(
OUTPUT ${CMAKE_BINARY_DIR}/a-converted.xml
COMMAND ./Convertor a.xml a-converted.xml
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/Convertor
)
add_custom_target(run ALL
DEPENDS ${CMAKE_BINARY_DIR}/a-converted.xml
COMMENT "Generating a-converted.xml" VERBATIM
)
install(
FILES ${CMAKE_BINARY_DIR}/a-converted.xml
DESTINATION ${INSTDIR}
)
Note: I don't have all the details, so the directories are probably
not exactly what you'd want in your environment, although it's
a good idea to generate files in the ${CMAKE_BINARY_DIR} area.
That way you can be sure that the file a-converted.xml is built at the time you want to install it. Especially, these two rules make sure that if you make changes to the file, it gets recompiled.
I am using libcurl for my utility and its working very well till now for all Linux platforms. I downloaded, unzipped and simply followed the instructions given without any changes. My product uses the libcurl.so file and is linked dynamically. The .so file is bundled along with our product. Recently there were issues in Suse wherein we found that Libcurl is bundled by default and there was a conflict in installation.
To avoid this issue we tried renaming the libcurl.so into libother_curl.so but it did not work and my binaries still show libcurl.so as a dependency through ldd. I had since learnt that the ELF format of linux shared objects specifies the file name hardcoded as SO file name in the headers.(I could verify the same with objdump -p).
Now my question is what is the simplest way to go? How do I build a libcurl with a different name? My original process involves running configure with the following switches
./configure --without-ssl --disable-ldap --disable-telnet --disable-POP3 --disable-IMAP --disable-RTSP --disable-SMTP --disable-TFTP --disable-dict --disable-gopher --disable-debug --enable-nonblocking --enable-thread --disable-cookies --disable-crypto-auth --disable-ipv6 --disable-proxy --enable-hidden-symbols --without-libidn --without-zlib
Make
Then pick the generated files from /lib/.libs
Are there any Configure Switches available wherein I can specify the target file name? Any specific Makefile I could change?
I tried changing in what I thought could be obvious locations but either could not generate the libs or were generated with the same name.
Any help is much appreciated.
I got the answer from the curl forums(Thanks Dan). Basically we have to use the makefile.am as a starting point to go through a list of files and change the library name "libxxx_curl".
$find . -name Makefile.am |xargs sed -i 's/libcurl(.la)/libxxx_curl\1/g'
$buildconf
$configure
$make
I lot of commercial applications bundle their particular library versions in a non standard path and then tweak environment variable LD_LIBRARY_PATH in a launch script so to avoid conflict. IMHO it is better than trying to change the target name.