dyld: Symbol not found: _ERR_remove_thread_state - libtorrent

I’m trying to run the make_torrent example code provide over here.
I’m have compiled and installed libtorrent based on what written over here
Here how I have complied and linked the make_torrent.cc file.
g++ -g -Wall make_torrent.cc -ltorrent-rasterbar -lboost_system -o make_torrent
Upon running the make_torrent sample code I see this
usage: make_torrent FILE [OPTIONS]
Generates a torrent file from the specified file
or directory and writes it to standard out
OPTIONS:
-m file generate a merkle hash tree torrent.
merkle torrents require client support
the resulting full merkle tree is written to
the specified file
-w url adds a web seed to the torrent with
the specified url
-t url adds the specified tracker to the
torrent. For multiple trackers, specify more
-t options
-c comment sets the comment to the specified string
-C creator sets the created-by field to the specified string
-p bytes enables padding files. Files larger
than bytes will be piece-aligned
-s bytes specifies a piece size for the torrent
This has to be a multiple of 16 kiB
-l Don't follow symlinks, instead encode them as
links in the torrent file
-o file specifies the output filename of the torrent file
If this is not specified, the torrent file is
printed to the standard out, except on windows
where the filename defaults to a.torrent
-r file add root certificate to the torrent, to verify
the HTTPS tracker
-S info-hash add a similar torrent by info-hash. The similar
torrent is expected to share some files with this one
-L collection add a collection name to this torrent. Other torrents
in the same collection is expected to share files
with this one.
-M make the torrent compatible with mutable torrents
this means aligning large files and pad them in order
for piece hashes to uniquely indentify a file without
overlap
dyld: lazy symbol binding failed: Symbol not found: _ERR_remove_thread_state
Referenced from: /usr/local/lib/libtorrent-rasterbar.9.dylib
Expected in: flat namespace
dyld: Symbol not found: _ERR_remove_thread_state
Referenced from: /usr/local/lib/libtorrent-rasterbar.9.dylib
Expected in: flat namespace
I know I have to provide the relevant argument to make torrent but I’m not sure why libtorrent is complaining about the linker
g++ --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Any clue?

This is caused by not linking to openssl correctly. I'm assuming you're on OSX, which has an old version of openssl in the default install path.
I would suggest installing openssl with brew install openssl. Note that this requires you have homebrew installed.
After doing this, do brew info openssl and look lines telling you what to add to your LDFLAGS and CPPFLAGS. In my case:
For compilers to find this software you may need to set:
LDFLAGS: -L/usr/local/opt/openssl/lib
CPPFLAGS: -I/usr/local/opt/openssl/include
For pkg-config to find this software you may need to set:
PKG_CONFIG_PATH: /usr/local/opt/openssl/lib/pkgconfig
So in my case, I would then compile with:
g++ -g -Wall -L/usr/local/opt/openssl/lib -I/usr/local/opt/openssl/include make_torrent.cc -ltorrent-rasterbar -lboost_system -o make_torrent
If this does not work, I would also make sure that you include these flags when compiling libtorrent.

Related

ld: building for macOS-x86_64 but attempting to link with file built for macOS-x86_64

I have this strange issue where creating / using a static library works in my Ubuntu VM but not on macOS:
ld: warning: ignoring file ./dist/libXXXX.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Command to create the static library is:
ar rcs libtest.a obj1.o obj2.o ...
Compiler invocation:
gcc -g -Wall -Wextra main.c -L./dist -lXXXX -o main
Searching on google didn't yield any usable results except for this (maybe) related question on SO:
Possible related question
I realize this is an old post and you found your fix, but let me post this here for anyone else who runs into this problem for whom these answers don't provide a solution.
You might be using two different toolchains unknowingly, one from Apple (installed via Xcode) and one from GNU (installed via Home-brew or MacPorts). If you type ranlib --version and see version info showing that ranlib is GNU, this is likely the case.
Make sure that /usr/bin comes in your $PATH before /usr/local/bin and /opt/local/bin. When you run which -a ranlib, the first result in the list should be /usr/bin/ranlib. Same for which -a ar-- the first result should be /usr/bin/ar. If it is not so, you need to fix your $PATH.
Once you fix your path and clean your project, try building again and things should work.
The issue was solved when I directly put those object files rather than gathering them into a static library, i.e.,
gcc -g -Wall -Wextra main.c obj1.o obj2.o -o main
After that, I got many warnings like ld: warning: object file (obj1.o) was built for newer macOS version (11.0) than being linked (10.14), but it is a warning, and the object is linked, so the problem is solved.
The root cause is that some library passes -mmacosx-version-min=10.14 to gcc, so the object file is built for 10.14, but my macos is now 11.0.
If you want to make things work, try directly using object files rather than creating a static library.
If you want to resolve all the warnings, find ``-mmacosx-version-min` and comment it.
After looking at my script that automatically creates the static library I've found the culprit:
For some reason my tool created object files for header files (resulting in files like header.h.o).
Removing those fixed the issue.

How to use openssl in cygwin? [duplicate]

I am trying to compile a small .c file that has the following includes:
#include <openssl/ssl.h>
#include <openssl/rsa.h>
#include <openssl/x509.h>
#include <openssl/evp.h>
In the same folder where I have the .c file I have a /openssl with all those files (and more), also in synaptic package manager I see OpenSSL installed, I am trying to compile with this:
gcc -o Opentest Opentest.c -lcrypto
but I always get the errors:
error: openssl/ssl.h: No such file or directory
error: openssl/rsa.h: No such file or directory
error: openssl/x509.h: No such file or directory
error: openssl/evp.h: No such file or directory
The file I want to compile is only a .c file, doesn't have Makefile or ./configure.
I already tried:
env CFLAGS=-I/path/to/openssl/
and tried to compile again but I get the same errors.
What should I do in order to compile with OpenSSL includes?
Your include paths indicate that you should be compiling against the system's OpenSSL installation. You shouldn't have the .h files in your package directory - it should be picking them up from /usr/include/openssl.
The plain OpenSSL package (libssl) doesn't include the .h files - you need to install the development package as well. This is named libssl-dev on Debian, Ubuntu and similar distributions, and openssl-devel on CentOS, Fedora, Red Hat and similar.
Use the -I flag to gcc properly.
gcc -I/path/to/openssl/ -o Opentest -lcrypto Opentest.c
The -I should point to the directory containing the openssl folder.
Use the snippet below as a solution for the cited challenge;
yum install openssl
yum install openssl-devel
Tested and proved effective on CentOS version 5.4 with keepalived version 1.2.7.
You need to include the library path (-L/usr/local/lib/)
gcc -o Opentest Opentest.c -L/usr/local/lib/ -lssl -lcrypto
It works for me.
If the OpenSSL headers are in the openssl sub-directory of the current directory, use:
gcc -I. -o Opentest Opentest.c -lcrypto
The pre-processor looks to create a name such as "./openssl/ssl.h" from the "." in the -I option and the name specified in angle brackets. If you had specified the names in double quotes (#include "openssl/ssl.h"), you might never have needed to ask the question; the compiler on Unix usually searches for headers enclosed in double quotes in the current directory automatically, but it does not do so for headers enclosed in angle brackets (#include <openssl/ssl.h>). It is implementation defined behaviour.
You don't say where the OpenSSL libraries are - you might need to add an appropriate option and argument to specify that, such as '-L /opt/openssl/lib'.
From the openssl.pc file
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: OpenSSL
Description: Secure Sockets Layer and cryptography libraries and tools
Version: 0.9.8g
Requires:
Libs: -L${libdir} -lssl -lcrypto
Libs.private: -ldl -Wl,-Bsymbolic-functions -lz
Cflags: -I${includedir}
You can note the Include directory path and the Libs path from this. Now your prefix for the include files is /home/username/Programming .
Hence your include file option should be -I//home/username/Programming.
(Yes i got it from the comments above)
This is just to remove logs regarding the headers. You may as well provide -L<Lib path> option for linking with the -lcrypto library.
For this gcc error, you should reference to to the gcc document about Search Path.
In short:
1) If you use angle brackets(<>) with #include, gcc will search header file firstly from system path such as /usr/local/include and /usr/include, etc.
2) The path specified by -Ldir command-line option, will be searched before the default directories.
3)If you use quotation("") with #include as #include "file", the directory containing the current file will be searched firstly.
so, the answer to your question is as following:
1) If you want to use header files in your source code folder, replace <> with "" in #include directive.
2) if you want to use -I command line option, add it to your compile command line.(if set CFLAGS in environment variables, It will not referenced automatically)
3) About package configuration(openssl.pc), I do not think it will be referenced without explicitly declared in build configuration.

Linking with libtcmalloc ubuntu

I had installed the package libtcmalloc-minimal0
but when I try to compile my program with flag
-ltcmalloc-minimal0
I am getting error
/usr/bin/ld: cannot find -ltcmalloc_minimal0
I had checked /usr/lib and the library is there
More Info
dpkg gives following o/p
dpkg -L libtcmalloc-minimal0
/.
/usr
/usr/lib
/usr/lib/libtcmalloc_minimal.so.0.0.0
/usr/lib/libtcmalloc_minimal_debug.so.0.0.0
/usr/share
/usr/share/doc
/usr/share/doc/libtcmalloc-minimal0
/usr/share/doc/libtcmalloc-minimal0/TODO
/usr/share/doc/libtcmalloc-minimal0/AUTHORS
/usr/share/doc/libtcmalloc-minimal0/copyright
/usr/share/doc/libtcmalloc-minimal0/changelog.gz
/usr/share/doc/libtcmalloc-minimal0/README.gz
/usr/share/doc/libtcmalloc-minimal0/changelog.Debian.gz
/usr/lib/libtcmalloc_minimal.so.0
/usr/lib/libtcmalloc_minimal_debug.so.0
and I am compiling for 64 bit mode
and library is also 64 bit
file /usr/lib/libtcmalloc_minimal.so.0.0.0
/usr/lib/libtcmalloc_minimal.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
You can't link simply to a file with -l if it doesn't end exactly with .so, since the linker assumes a particular naming convention (lib*.so).
You have several choices:
Install libtcmalloc-minimal0-dev if it exists, which should provide the .so dynamic link.
Create the symlink yourself: cd /usr/lib; ln -s libtcmalloc_minimal.so.0.0.0 libtcmalloc_minimal.so; cd -
Link directly to the library without the symlink by using gcc test.c /usr/lib/libtcmalloc_minimal.so.0.0.0
Link using the -l option using the full name: -l:libtcmalloc_minimal.so.0.0.0
Running dpkg -L libtcmalloc-minimal0 will show you that the library is /usr/lib/libtcmalloc_minimal.so.0 so the correct option should be -ltcmalloc_minimal without any digit

could not read symbols: Archive has no index; run ranlib to add one

i tried making library with
ar -r -c -s libtestlib.a *.o
as given in this tutorial http://matrixprogramming.com/Tools/CompileLink.html
But on linking with library following error comes
g++ -o uni2asc uni2asc.o -L../Modules -ltestlib
../Modules/libtestlib.a: could not read symbols: Archive has no index; run ranlib to add one
collect2: ld returned 1 exit status
i tried with ranlib also but still the error comes..
im working with ubuntu9.10
Please suggest me some solution for this
Your archive command looks fine, can you try the following.
1) Get the object files in the archive/static library
ar -t libtestlib.a
2) For each object file (say foo.o) from step 1
file foo.o
This will tell you the format of the object file. If the object file was compiled for a different platform, this would cause a failure to build the index for the archive.
To correct this you would need to recompile these files.
3) For each object file from step 1, do
nm foo.o
This will list the symbols exported from the file.
I was using MinGW to compile a windows app when I got the error, so I found the built-in MinGW commands:
i686-w64-mingw32-ar
And
x86_64-w64-mingw32-ar
Try using those instead of ar if you encounter the problem in MinGW. They both fixed the question's problem for me.
libtool also has an useful option:
-export-symbols-regexp.
I ran into the exact same problem when trying to compile the NBIS libraries. There is an option for
make install LIBNBIS=yes
which creates a single archive containing the other archive files. The gcc linker does not handle this gracefully and just emits the Archive has no index message. The fix is to leave the archives as separate files
make install LIBNBIS=no
Then just link the application to the required archive(s). The archive feed order is important to be sure that the linker identifies the required dependencies, then resolves them as it processes the .a files.

Problem with linking against libexpat in Boost Build - for building graphml

On my system, expat is located at
/usr/include/expat.h
/usr/include/expat_external.h
/usr/lib/libexpat.1.5.0.dylib
/usr/lib/libexpat.1.dylib
/usr/lib/libexpat.dylib
/usr/lib/libexpat.la
So I export the required variables for boost to build graphml
export EXPAT_INCLUDE=/usr/include
export EXPAT_LIBPATH=/usr/lib
then I run (where $DIR and $BOOST generate the paths I want the includes and libs to go)
./configure --includedir=$DIR/$BOOST --libdir=$DIR/$BOOST/lib \
--with-libraries=test,graph
I get this error:
ld: library not found for -lexpat collect2: ld returned 1 exit status
which boost says is caused by the line:
g++ -dynamiclib -install_name "libboost_graph-mt-1_35.dylib" -L"/usr/lib"
-o "bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/libboost_graph-mt-1_35.dylib"
"bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/read_graphviz_spirit.o"
"bin.v2/libs/graph/build/darwin/release/macosx-version-10.4/threading-multi/graphml.o"
-lexpat -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -Wl,-dead_strip -no_dead_strip_inits_and_terms
I don't get how it's not finding the expat library with -L"/usr/lib" and -lexpat as arguments? My understanding is that /usr/lib/libexpat.dylib is exactly referenced as -L"/usr/lib" and -lexpat.
The Jamfile for building graphml is here. If EXPAT_INCLUDE and EXPAT_LIBPATH aren't set then it warns you (lines 39-41 of jamfile)
warning: Graph library does not contain optional GraphML reader.
note: to enable GraphML support, set EXPAT_INCLUDE and
note: directories containing the Expat headers and libraries, respectively.
Another update:
I don't see an .so or a .a file in your list of where EXPAT is... doesn't that seem a bit strange? Normally it will create an alias for the library name
for example /usr/lib/libblah.so -> /usr/lib/libblaah.so.1.2
Is dynalib some Macintoshism (I don't use Macs much)
is .la the static version extension on this platform?
Update:
The quotes around the path seem troublesome...
-L"/usr/lib"
Try changing this to -L/usr/lib and -L /usr/lib
Older stuff:
The directive for the linker to include paths during the link step is -L. You need to look for some linker flags to update to include -L path_to_expat. I don't think the linker pays any attention to LD_LIBRARY_PATH. I am not sure what documentation you have read to set EXPAT_INCLUDE or EXPAT_LIBPATH.

Resources