I am trying to build heimdal package for msys2. To my dismay, during linking of the first constituent library, roken, dlls fail to be built, and that causes sort of a chain reaction further on.
The only message i get is:
libtool: undefined symbols not allowed in x86_64-pc-msys shared ... only static will be built
however, there is no information provided on what symbols are undefined. How can i find that out?
If i turn on output of commands wuth make V=1 i get libtool command that links from a large numbert of .lo files. If i try to run gcc over them (copying command from there), it does not recognize them as anything.
I am trying to follow instructions as outlined in msys2 package build script for heimdal.
On Windows building a shared library while allowing undefined symbols is not allowed.
Try to build with the -Wl,-no-undefined linker flag, for example by adding LDFLAGS="-Wl,-no-undefined" to the ./configure command.
If that didn't work try this after ./configure and before make:
sed -i.bak -e "s/\(allow_undefined=\)yes/\1no/" libtool
If you already had a failed build earlier you should also clean up any .la files like this before running make again:
rm $(find -name '*.la')
Related
I'm trying to build ClickHouse in CLion.
I follow the official documentation. I was able to build ClickHouse from the command line, however, I would also like to be able to build it in CLion.
The documentation doesn't give out much information on how to do that, only implies that it's possible. ClickHouse's GitHub Issues search by 'CLion' also do not offer much advice.
ClickHouse uses CMake and Ninja. The documentation mentions that one can use either Ninja or make instead of Ninja to compile in CLion.
I tried both and got many errors. For example, when running with CMake settings set to -G Ninja, I was able to build the target common but I get the following error when building the target clickhouse-client:
====================[ Build | clickhouse-client | Debug ]=======================
/usr/bin/cmake --build /tmp/tmp.CAA3nJhi8z/cmake-build-debug --target clickhouse-client
[1/7338] Generating lber-version.c
FAILED: contrib/openldap-cmake/lber-version.c
cd /tmp/tmp.CAA3nJhi8z/contrib/openldap && /usr/bin/cmake -E env bash -c "/tmp/tmp.CAA3nJhi8z/contrib/openldap/build/mkversion -v '2.5.X' liblber.la > \"/tmp/tmp.CAA3nJhi8z/cmake-build-debug/contrib/openldap-cmake/lber-version.c\""
bash: /tmp/tmp.CAA3nJhi8z/contrib/openldap/build/mkversion: Permission denied
[18/7338] Building CXX object contrib/..._/icu/icu4c/source/i18n/calendar.cpp.o
ninja: build stopped: subcommand failed.
I also use a remote toolchain in CLion to build on a server, not my laptop. Since it's a permission issue, I assume I have to run the build from sudo but I'm not sure how to do that, and searching only offers a guide on How to debug as root in CLion.
Question #2. Is it OK that after CMake loaded in CLion, I don't see any green arrows in the CMakeLists.txt in the root of the ClickHouse project? I can only see targets in the top right corner dropdown (screenshot).
Question #3. I'm also unsure how to build all the binaries in CLion. E.g. in the command line, I would just run ninja but in CLion there are so many targets, and none of them is named like build all.
Any pointers to a solution are much appreciated.
It might be helpful to someone to answer your first question.
Since you are using a remote build, the Clion first copies all source files to the remote machine. And if the option
Settings -> Build,Execution,Deployment -> Deployment -> Options -> Preserve original file permissions
is not enabled, it does not save the executable permissions to run some scripts. Which breaks the build.
Therefore, you can either enable this option and re-upload the files or set permission x manually to the files that will be logged in the error message.
I am getting the following error :
CMake Error at CMakeLists.txt:9 (BISON_TARGET):
Unknown CMake command "BISON_TARGET".
when I run the command :
cmake .. -GNinja
Please tell me what to do. I tried searching on google a lot and thus came up with the additions and finally ran the command :
cmake .. -D LLVM_DIR=/usr/lib/llvm-5.0/cmake/ -D FLEX_EXECUTABLE=/usr/local/Cellar/flex/2.5.37/bin/ -D FLEX_INCLUDE_DIR=/usr/local/Cellar/flex/2.5.37/include/ -D BISON_EXECUTABLE=/usr/bin/bison
but it still shows the same error :(.
Please someone help.
Your error is occurring because the BISON_TARGET function definition has not yet been supplied. This method, as commented, is supplied by FindBISON. The error indicates that either Bison was not found on your system (hopefully, you have it installed), or cmake was ran from the wrong directory. Bison is included in the top-level CMake file via:
find_package(BISON REQUIRED)
This line to include Bison must be called before using the BISON_TARGET CMake function. The LLReve instructions for compiling this repository are explicit about which directory to run the build commands in:
Go to the llreve directory and run
cd reve
mkdir build
cd build
cmake .. -GNinja
ninja
This would run on the CMake file in the llreve/reve directory, not the llreve/reve/reve directory. Please ensure you are running CMake from the correct location, as not running cmake on the top-level CMake file will often yield errors.
I downloaded the source files for wget and tried to compile it with Clang. I want to configure with the link time optimization (-flto). At first, I simply tried:
./configure CC=clang CFLAGS=-flto
make
The configuration was successful, but I could not run make which output:
/tmp/lto-llvm-4f0f02.o:ld-temp.o:function _do_handshake: error: undefined reference to 'rpl_fcntl'
and other numerous similar errors, all of the same format (error: undefined reference to xxx).
So I thought I needed to link the files correctly. After searching for answers, I then tried all of the following commands:
./configure CC=clang CFLAGS=-flto LDFLAGS=-flto
make
-----------------------------------------------
./configure CC=clang CFLAGS=-flto LDFLAGS="-fuse-ld=lld-4.0"
make
-----------------------------------------------
./configure CC=clang CFLAGS=-flto LDFLAGS="-fuse-ld=gold"
make
But I am still getting the same error.
I am running this on Debian-9.5. What am I missing?
You need to also specify the specific ar utility to use - the default ar and ranlib produce .a files that are unusable for linking (no entries to use), so for me this worked:
./configure CC=clang-4.0 CFLAGS=-flto AR=llvm-ar-4.0 RANLIB=llvm-ranlib-4.0
You may get away with just llvm-ar, without the version postfix, but you need to ensure that the clang, ar, and ranlib versions match, otherwise you encounter other errors.
I have written a programm in c++. Linking and runiing is working, as long as I don't use the "-static" option for g++. But I have to run it from an Antergos USB-Live Stick with default settings and there is no GSL included. In the manual of GSL they recommend
$ g++ -c main.cpp
$ g++ -static main.o -lgsl -lgslcblas -lm -lnlopt
But for this code I receive an error message:
/usr/bin/ld: cannot find -lgsl
/usr/bin/ld: cannot find -lgslcblas
collect2: Fehler: ld gab 1 als End-Status zurück
I tried it as this question, but it didn't work for me. When I run
$ g++ -O2 -o test main.cpp -lgsl -lgslcblas -lnlopt -lm
$ lld test
it prints
linux-vdso.so.1 (0x00007fffa5b95000)
libgsl.so.19 => /usr/lib/libgsl.so.19 (0x00007f8748c9a000)
libgslcblas.so.0 => /usr/lib/libgslcblas.so.0 (0x00007f8748a5d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f87486d5000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f87483d1000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f87481ba000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f8747e1c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f87490fe000)
So I tried to create a symlink, but I do have also "libgsl.so"
$ ls /usr/lib/libgsl
libgslcblas.so libgslcblas.so.0.0.0 libgsl.so.19
libgslcblas.so.0 libgsl.so libgsl.so.19.3.0
Am I doing something stupid? Thank your for your help.
When you pass -lgsl, by default you request the linker to
find and link either the shared library libgsl.so or the static
library libgsl.a and to prefer the shared library, if both are found
in the same search directory. The linker will search, first, in any
directories you have specified with the -L/path/to/search options,
in the order you specified, and then in its default search directories
(/usr/lib, etc.). Likewise for -lgslcblas.
But when you pass the linkage option -static to gcc/g++, it prevents
linking with any shared libraries. Shared libraries, libgsl.so, libgslcblas.so
will be ignored. Static libraries libgsl.a, libgslblas.a, must be
found, in some or other of the search directories, for the linkage to
succeed.
The linker is saying:
/usr/bin/ld: cannot find -lgsl
/usr/bin/ld: cannot find -lgslcblas
because it can't find those static libraries - presumably because you
haven't installed them.
You do not say what linux distro you are working on, but if the package
that provides libgsl and libgslcblas is called, say, libgsl[suffix]
then there will be a corresponding package called libgsl-dev, libgsl-devel,
or similar. This will be the development version of the package,
for the use of people who want to develop software that links with libgsl
or libgslcblas. The development package will require the libgsl package as a dependency
- so it will install the same stuff - and will in addition contain the
library's header files and the static version of the library.
So you need to install the libgsl development package for your distro.
For Ubuntu, for example, that is libgsl-dev:
Later
I gather that your distro, Arch Linux, does not do separate dev packages. You
need to build the static libraries from source. To do that you will need
at least to have installed:
GNU Make
GNU autotools (autoconf, automake, libtool)
GCC (C compiler)
texinfo
Then to make a default build:
Get the gsl source package from https://savannah.gnu.org/git/?group=gsl
either by cloning the git repo or downloading a current tar.gz tarball
and extracting it.
cd into the package directory.
run ./autogen.sh. This will succeed provided the GNU autotools prerequisites
are fulfilled.
run ./configure --enable-maintainer-mode (as ./autogen.sh will have prompted you).
This will succeed provided that the package dependencies are satisfied
and environment sanity checks pass.
run make
If make completes without errors - which will take a matter of minutes -
then, as root, run make install.
If all is well, this will install your missing static libraries:
/usr/local/lib/libgsl.a
/usr/local/lib/libgslcblas.a
You should not need to modify your linkage command for the linker to find
them: /usr/local/lib is a default linker search path.
I want to generate a dll file in MinGW, I have several object dependencies in order to do that, one of my object dependencies is libdl.so, I add this object in unix simply as :
g++ xx.o yy.o /usr/lib/libdl.so -o module.so
but in MinGW, I don't have any idea how to add this object. any ideas?
There is a MinGW port of libdl that you can use just like under Unix. Quote from the website:
This library implements a wrapper for dlfcn, as specified in POSIX and SUS, around the dynamic link library functions found in the Windows API.
It requires MinGW to build.
You may get pre-built binaries (with MinGW gcc 3.4.5) and a bundled source code from the Downloads section.
The following commands build and install it in a standard MinGW installation (to be run from your MinGW shell):
./configure --prefix=/ --libdir=/lib --incdir=/include && make && make install
To compile your library as a DLL, use the following command:
g++ -shared xx.o yy.o -ldl -o module.dll
I encountered the same problem (msys2, 32bit version of compiler etc.).
For me I found out that the libdl.a was available in /usr/lib but not in /mingw32/lib. I was able to solve the problem by linking it to the /mingw32/lib folder:
ln -s /usr/lib/libdl.a /mingw32/lib