在编译时mpich,我收到了一些relinking警告......
libtool: warning: relinking 'lib/libmpicxx.la'
我无法通过Google搜索错误消息找出这些含义.什么是relinking？为什么会引起它,我怎么能摆脱它呢？
我正在编写自己的单元测试库(使用autoconf,automake和libtool)以更好地满足我的需求(我不需要超大量的功能,只需要测试运行器和断言).我已经达到了似乎可以使用的程度.
当然,它使用config.h来确定要包含的标头.问题是,我不知道在哪里的config.h应该去,因为它往往会与其他项目的config.h中,以及事实,即它是依赖于架构容易冲突.
我的方法应该用于安装此标头？(所有其他标题都需要它)
我有几个C++类,我想使用autotools和libtool将它们编译成一个共享库.这些是我的configure.ac和Makefile.am文件:
configure.ac:
AC_PREREQ(2.67)
AC_INIT(somelib.so, 1.0, someone@somewhere.com)
AC_LANG(C++)
AM_INIT_AUTOMAKE(somelib, 1.0)
LT_INIT([disable-static])
AM_DISABLE_STATIC
AM_PROG_LIBTOOL
AC_LIBTOOL_DLOPEN
AC_PROG_LIBTOOL
AC_CONFIG_SRCDIR([Logger.cpp])
AC_CONFIG_HEADER([config.h])
# Checks for programs.
AC_PROG_CXX
AC_PROG_CC
AC_SUBST(LIBTOOL_DEPS)
AC_LTDL_DLLIB
AC_PROG_RANLIB
AC_SUBST(LIBTOOL_DEPS)
AC_LTDL_DLLIB
# Checks for libraries.
# Checks for header files.
AC_HEADER_STDC
AC_CHECK_HEADERS([cstring unistd.h pthread.h])
# Checks for typedefs, structures, and compiler characteristics.
AC_HEADER_STDBOOL
AC_C_CONST
AC_C_INLINE
AC_TYPE_SIZE_T
# Checks for library functions.
AC_FUNC_MALLOC
AC_FUNC_REALLOC
AC_TYPE_SIGNAL
AC_CHECK_FUNCS([mkdir strdup dup2])
AC_CHECK_LIB(pthread, pthread_create, [], [ echo "ERROR!: libpthread not found!"; exit -1], [])
AC_CHECK_LIB(xml2, htmlReadMemory, [], [ echo …我想构建一个使用GNU Autotools使用ZipArchive的共享库,但我遇到了这个问题:
Warning: linker path does not have real file for library -lziparch. I have the capability to make that library automatically link in when you link to this library. But I can only do this if you have a shared version of the library, which you do not appear to have because I did check the linker path looking for a file starting with libziparch and none of the candidates passed a file format test using a file magic. …
如何在不重新排序的情况下将 --whole-archive 与 libtool 一起使用？
背景： 我正在从依赖于依赖于 libdwarf 的 Dyninst 的源编译 Extrae（性能分析），后者在 Debian Wheezy 上作为静态库 (usr/lib/libdwarf.a) 提供。
Dyninst 是从以下来源编译的：
# ./configure --with-libdwarf-static; make; make install
创建：
/usr/lib/libdynDwarf.so.8.1
/usr/lib/libdyninstAPI.so.8
然后从源代码编译 Extrae 。
# ./configure --with-mpi=/usr --with-mpi-libs=/usr/lib --with-papi=/usr/local --with-unwind=/usr --with-dyninst=/usr --with-dwarf=/usr --with-dwarf-libs=/usr/lib
...
# make
...
/bin/sh ../../../libtool --tag=CXX --mode=link g++ -I../../../src/common -I/usr/include -g -O2 -Wall -W -L/usr/lib64 -ldyninstAPI -L/usr/lib64 -lunwind -lparseAPI -lsymtabAPI -linstructionAPI -lcommon -L/usr/lib -ldwarf -lelf -L/usr/lib -lxml2 -o extrae extrae-extrae.o extrae-forkSnippets.o extrae-cudaSnippets.o extrae-ompSnippets.o extrae-apiSnippets.o extrae-mpiSnippets.o extrae-commonSnippets.o extrae-applicationType.o …我有一个不起作用的设置,我不知道我在这里做错了什么 - 我正在尝试将项目从手工制作的Makefile转换为autotools,我认为我的大部分设置正确,因为应用程序和它的所有便利库都可以正确构建和链接,但是便利库的全局状态初始化器存在一些问题.
一些库在代码中遵循这样的模式:
// in global scope of somemodule.cpp
namespace {
bool registered = ModuleShare::registerModule<SomeModule>("SomeModule");
}
此代码与实际模块源一起使用libtool编译到便捷库中
// libsomething Makefile.am
noinst_LTLIBRARIES = libsomething.la
libsomething_la_SOURCES = \
[ ... ]
moduleshare.cpp moduleshare.h \
somemodule.cpp somemodule.h \
[ ... ]
并且构建了这个库,并在应用程序Makefile.am中引用如下:
// someapp Makefile.am
bin_PROGRAMS = someapp
someapp_SOURCES = someapp.c someapp.h
someapp_CPPFLAGS = -I ${top_srcdir}/something
someapp_LDADD = ${top_srcdir}/something/libsomething.la
我修改了ModuleShare :: registerModule来验证它没有被调用:
template<typename T>
static bool registerModule(const std::string &module){
printf("%s\n", module.c_str());
[ ... ]
return true;
}
这可能是什么原因？
编辑:
此时,我已经发现这个问题与链接器有关,链接器允许在链接期间删除未使用的符号.如果我手动链接使用--whole-archive,一切都按预期工作. …
我的.la文件在dependency_libs=部分和libdir=部分都有完整的路径名,这使得我很难将我的库复制到不同的机器(相同的拱但不同的路径结构).有什么解决方案,除了有一些脚本来破解.la文件以调整新机器上的路径？
== ==详细
当我./configure; make; make install我的libfoo,这取决于我如何使用--prefix,--exec-prefix以及DESTDIR=标志,我会得到一个条目libfoo.la,读取文件libdir=/dir1/lib,我将有实际的.so在同一目录的文件libfoo.la.一切都很顺利(就连接的问题而言libfoo),直到我将它们打包并放在另一台机器上.
假设libbar我的第二台机器依赖于libfoo.当我使用我的-L/dir2/lib标志来查找时-lfoo,libbar编译/链接失败,因为libfoo.la文件期望foo安装在/dir1/lib(从第一台机器)实际进入时/dir2/lib.然后我需要dir1用正确的路径替换所有的路径,这两个路径都可能很长而且很复杂.
该dependency_libs=线也以类似的方式发挥作用.
我该如何避免这个问题？
习惯了之后就舒服GNU autoconf了GNU automake。我决定开始学习libtool. 但我仍然无法清楚地看到在现实世界中使用它的好处。
据我了解，主要好处是主要的可移植性问题，即系统是否支持动态库。然而，现在大多数都是主要UNIX-like OS的GNU/Linux，BSD-flavors或者Mac OS很难面对OS不支持动态库或具有奇怪的库标准的情况。
所以这是我的问题，它值得使用吗libtool？
我正在尝试使用构建链代码go build.当我运行Go build命令时它的报告
.\hyperledger\fabric\vendor\github.com\miekg\pkcs11\pkcs11.g??o:29:18:
fatal error:ltdl.h: No such file or directory
compilation terminated
我从这个链接安装了libtools .但我得到了同样的错误
我已在我的默认环境中安装并更新tmux并emacs通过conda以下版本conda list:
# packages in environment at /home/maxghenis/miniconda3:
#
# Name Version Build Channel
tmux 2.7 hc78d2af_1 conda-forge
emacs 26.1 h3a2ea38_1 conda-forge
然而,当试图开始tmux或者emacs,我得到这个错误:
error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory
每错误而载入共享库:libgsl.so.0:无法打开共享对象文件:没有这样的文件或目录我有5个libtinfo文件:
(xenial)maxghenis@localhost:~$ sudo find / -name "libtinfo.so"
/home/maxghenis/miniconda3/pkgs/ncurses-5.9-10/lib/libtinfo.so
/home/maxghenis/miniconda3/pkgs/ncurses-6.1-hf484d3e_0/lib/libtinfo.so
/home/maxghenis/miniconda3/envs/tidycensus/lib/libtinfo.so
/home/maxghenis/miniconda3/lib/libtinfo.so
(xenial)maxghenis@localhost:/lib$ sudo find / -name "libtinfo.so.6"
/lib64/libtinfo.so.6