Xcode "ld: library not found [...] for architecture x86_64" - xcode

I want to include libgpg-error and libgcrypt in my swift-project and created the following module.modulemaps:
libgpgerror:
module libgpgerror {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/gpg-error.h"
link "'/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/libgpgerror-1.21.dylib'"
export *
}
libgcrypt:
module libgcrypt {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgcrypt/gcrypt.h"
link "'/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgcrypt/libgcrypt-1.6.5.dylib'"
export *
}
I also added the "Swift Compiler - Search Path/Import Paths": /Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/** to both project and target.
The modules are found, the paths are correct.
However if I want to compile the project I get the following error:
ld: library not found for -l'/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/libgpgerror-1.21.dylib' for architecture x86_64
But if I do
file /Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/libgpgerror-1.21.dylib
I get the output
/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/libgpgerror-1.21.dylib: Mach-O 64-bit dynamically linked shared library x86_64
So it seems the library is in the correct place and also has the correct architecture.
Edit
I found a workaround: I removed the link-directive from the modulemaps and linked the libraries manually; this seems to work. But why?
module libgpgerror {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgpgerror/gpg-error.h"
export *
}

The link directive specifies only the name of the linked library. That is it should specify the suffix of the linker flag for the library. It appears that the directive take "-l" and concatenates the name to produce the linker flag.
This means that the correct way to specify your module map is as follows.
module CGcrypt {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgcrypt/gcrypt.h"
link "gcrypt"
export *
}
This will generate the linker flag -lgcrypt which is the correct linker flag.
However, there is another problem which is that the linker needs to be able to find the dylib file for gcrypt and by default it only looks on certain paths. Those paths can be found by running clang -Xlinker -v. The output for me looks like this:
tylercloutier$ clang -Xlinker -v
#(#)PROGRAM:ld PROJECT:ld64-264.3.101
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
Library search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib
... more stuff ...
Now I'm not sure, but I suspect that the normal search paths are probably
/usr/lib
/usr/local/lib
but I think that Xcode has altered my search paths to point the the MacOSX10.11.sdk/usr/lib, which, incidentally, has basically the same set of files as /usr/lib (they are not symlinked). Indeed, in El Capitan, because of System Integrity Protection even sudo will not allow you to edit /usr/lib.
Thus the problem that I am having is that even though I've installed my libraries to /usr/local/lib, clang is not able to link them. In order to fix that I can specify the search path explicitly.
swift build -Xlinker -L/usr/local/lib/
And we're off to the races. I can even generate an xcodeproj which will have the appropriate linker flag already set in Other Linker Flags.
swift build -Xlinker -L/usr/local/lib/ --generate-xcodeproj
If you leave out the link directive in the module map file, you can specify it as a flag:
module CGcrypt {
header "/Volumes/Xcode/Programme/Swifts/KCAnon/KCAnon_Client/Libs/libgcrypt/gcrypt.h"
export *
}
Like so
swift build -Xlinker -L/usr/local/lib/ -lgcrypt
How to change the default library search paths, I don't know. But it would be great if someone else could shed light on this matter!

Related

Linking ports libraries under FreeBSD

I have built some libraries (gtk3, qt5, ...) through the ports collection under FreeBSD 11.2. In order to test them I just built minimal examples. Each time the linker complains about not finding these libraries.
Correct me if I am wrong, but under FreeBSD, regular packages (those which are setup with pkg) are installed under /usr/include and /usr/lib, however ports lie, by default, under /usr/local/include and /usr/local/lib.
Is there a simple way to tell the compiler to search under these directories rather than having huge compilation commands with the -I and -L options?
Thank you for your answers.
Edit
Here is my CMakeLists.txt:
cmake_minimum_required(VERSION 3.12)
project(gtk-test)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/modules/")
find_package(GTK3 REQUIRED)
include_directories(${GTK3_INCLUDE_DIRS})
link_directories(${GTK3_LIBRARY_DIRS})
add_executable(gtk-test gtk-test.c)
target_link_libraries(gtk-test ${GTK3_LIBRARIES})
I have solved the dependencies issue by grabbing the following CMake script:
https://github.com/eiskaltdcpp/eiskaltdcpp/blob/master/cmake/FindGTK3.cmake
However, another problem has pop up:
[100%] Linking C executable gtk-test
/usr/lib/crt1.o: In function `_start':
crt1.c:(.text+0x91): undefined reference to `main'
collect2: error: ld returned 1 exit status
Edit
I am stupid, I even did not notice that there was no main function in the sample. It works fine except that, by default, CMake cannot locate GTK3 library and its dependencies.
Here is the content of my CMake config scripts:
Qt5
Qt53DQuick
Qt53DRender
Qt5DataVisualization
Qt5Location
Qt5OpenGLExtensions
Qt5QuickTest
Qt5SerialBus
Qt5UiPlugin
Qt5WebKit
Qt5XmlPatterns
Qt53DAnimation
Qt53DQuickAnimation
Qt5Bluetooth
Qt5Designer
Qt5Multimedia
Qt5Positioning
Qt5QuickWidgets
Qt5SerialPort
Qt5UiTools
Qt5WebKitWidgets
assimp-4.1
Qt53DCore
Qt53DQuickExtras
Qt5Charts
Qt5Gamepad
Qt5MultimediaWidgets
Qt5PrintSupport
Qt5Script
Qt5Sql
Qt5WebChannel
Qt5WebSockets
harfbuzz
Qt53DExtras
Qt53DQuickInput
Qt5Concurrent
Qt5Gui
Qt5Network
Qt5Qml
Qt5ScriptTools
Qt5Svg
Qt5WebEngine
Qt5Widgets
libxml2
Qt53DInput
Qt53DQuickRender
Qt5Core
Qt5Help
Qt5Nfc
Qt5Quick
Qt5Scxml
Qt5Test
Qt5WebEngineCore
Qt5X11Extras
Qt53DLogic
Qt53DQuickScene2D
Qt5DBus
Qt5LinguistTools
Qt5OpenGL
Qt5QuickControls2
Qt5Sensors
Qt5TextToSpeech
Qt5WebEngineWidgets
Qt5Xml

Issue when linking lapack and fftw3 libraries

I have a Fortran 90 program which uses lapack subroutines, and is successfully running on my Ubuntu system. Now I want to run it on Mac (OS X Version 10.11.4). I am using gfortran compiler as a part of gcc, installed from homebrew repositories, and lapack library, installed in /usr/local/lib/.
When I try to compile my code, I get the following error:
gfortran my_prog.f90 -L/usr/local/lib/ -llapack
Undefined symbols for architecture x86_64:
"_daxpy_", referenced from:
_zggbal_ in liblapack.a(zggbal.o)
...
"_ztrmv_", referenced from:
_zlarft_ in liblapack.a(zlarft.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
After some google search I understood that the problem is because the linking. When I compile it like this, everything works well:
gfortran my_prog.f90 -llapack
Also when llapack from framework accelerate is used, the compiler doesn't complain.
gfortran my_prog.f90 -framework accelerate
The libraries are of x86-64 architecture:
lipo -info *.a
input file libfftw3.a is not a fat file
input file liblapack.a is not a fat file
Non-fat file: libfftw3.a is architecture: x86_64
Non-fat file: liblapack.a is architecture: x86_64
LAPACK is not the only one which gives me an error, later the same problem appears with FFTW3. Could you please give me a hint to the solution to this problem?
FFTW is not part of the accelerate framework. If you want to use it, you need to add -lfftw3 to the compile options as well.
If the libraries are not in the default LIBRARY_PATH, you might need to specify -L/path/to/fftw/libs as well. The same holds for the include path if you are using its modules -I/path/to/fftw/includes.
Note that the vDSP part of the library also provides FFT implementations. You might not need FFTW at all.

automake program libtool wrapper linking

Am stumped on an automake link. Even after pouring over the manuals for hours and searching online it is probably a misunderstanding of autotools.
I have one .la library made by libtool, one .dylib shared library and am creating a program. The .la is linked to the .dylib and the program uses the .la.
Makefile.am for the .la library
lib_LTLIBRARIES = libA.la
libA_la_LDFLAGS = ${AM_LDFLAGS} -no-undefined
libA_la_LIBADD = $(LIBM) -Ldir/to/ -lB
libA_la_CPPFLAGS = ${AM_CPPFLAGS}
Makefile.am for program with libtool wrapper
noinst_PROGRAMS = test
test_SOURCES = test_source.c
test_LDADD = libA.la -Ldir/to/ -lB
libA.la is created and links to B.dylib but the test program "wrapper" created by automake is exporting DYLD_LIBRARY_PATH to find libA.la while not linking to B.dylib. Giving the error
dyld: Library not loaded: ./B.dylib
Referenced from: /dir/to/test/.libs/test
Reason: image not found
Trace/BPT trap: 5
Some things that I have tried are adding -Ldir/to/ -lB to test_LDFLAGS in addition to already being added in test_LDADD. And have tried setting test_LDFLAGS = -rpath -Ldir/to in the hopes that setting the runtime search path to the directory where B.dylib is would help.
If I manually export DYLD_LIBRARY_PATH to include /dir/to/B.dylib then the test program is able to run but I'm looking to have autotools take care of this rather than requiring someone to export a path before being able to run it.
libB.dylib includes an rpath that gets copied into your binary and that is used to resolve -lB at runtime.
And it seems that this rpath is not /path/to, so libB.dylib cannot be resolved by the runtime linker.
The reasons why it works for libA.la is that libtools knows that the rpath in libA.dylib is wrong anyhow (as you haven't done a make install) and so it needs to be set manually.
The only way around this that i have found is to use install_name_tool to fix the stored rpath in the resulting binary.
(that is: I don't think that libtool will do this for you, as it contradicts the intended use of libB.dylib - as declared in its rpath)
The problem is that Libtool wasn't involved in building libB.dylib, so it does not know how to fix up your environment to find it. That means it is up to you. You can add path/to/ libB in your environment, or add a hardcoded search path to libA.la so that libA will find it.
libA_la_LIBADD = $(LIBM) -Ldir/to/ -rpath dir/to/ -lB
This will not only add the path to B in libA's binary, but will add it to dependency-libs in Libtool's libA.la file so that on platforms that won't automatically inherit the rpath specification it can be added by Libtool when linking.

Cannot get FreeType library to work in Mac OS X Mountain Lion

I have an OpenGL project which works/compiles fine in Windows.
I wanted to port the application to Mac OS.
I got the application up and running on Mac, but the text inside the project is not visible. So I decided to use a 3rd party library for text rendering in Mac, I came across FreeType, which has many advantages such as anti-aliasing and UNICODE support.
So, I downloaded the library on my Mac, './configure'd it, did 'make' and 'make install' as I would normally do.
Then in Xcode I set search paths for both include and library directories,
/usr/local/include and /usr/local/lib respectively. Then I added 'other linker flags' in Xcode, freetype-configure --libs gave me following flags- -L/usr/local/lib -lfreetype -lz -lbz2, I added them in Xcode.
Now, whenever I include a freetype header there is no problem, but when I call any method from the freetype library, it gives me following linker error.
After looking up on google I found out that I have to set the build targets accordingly, I did that, now my application builds for i386 x86 the issue still persist.
I also tried following flags while configuring freetype ./configure CC="gcc -arch i386" CXX="g++ -arch i386"
which did not help either.
I am relatively new to Mac OS X/Unix environment, I have previously got freetype working on windows with VS 2008. Any help would be greatly appreciated.
What:
It seems you have more than one libfreetype.dylib file in your library search paths.
/master_repository/......../lib contains one and /usr/local/lib contains another
-lfreetype is a convenient way of telling the linker to look for file named libfreetype.dylib in all the directories specified with -L flags. Because -L/master_repository... comes before -L/usr/local/lib in the linker argument list, the linker uses the first instance it finds and attempts linking to that one.
Fix:
Reorganising your -L flags so that -L/usr/local/lib comes before the other. Avoid this option if you can.
Removing the extra search path, leaving only the relevant one.
Specifying the library explicitly instead of relying on the convenient -l by replacing -lfreetype with a full path to a library: /usr/local/lib/libfreetype.dylib

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