I am now building a dynamic library and an command line illustration program that uses this dynamic library. The library and the illustration program are in the same folder:
/user/xxx/develop/debug/libdynamic.dylib
/user/xxx/develop/debug/illustration
When the illustration program can work very well in my computer, I send the illustration program as well as the dynamic library to my colleague and he will run the illustration program in his computer. However, every time he runs the illustration program in the command window, the program also reminds that it can not load the libdynamic.dylib as it tries to find the library in /user/xxx/develop/debug/, which is unavailable in my colleague's computer. I was wondering what I should do. Many thanks.
EDIT:
The output using otool for the illustration program is as follows:
/Users/xxx/develop/debug/libdynamic.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.18.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
You need to tell illustration where to find libdynamic.dylib which you can do post-build using install_name_tool (manpage). You'll want to set the new path to #executable_path/libdynamic.dylib, with (something like):
$ install_name_tool -change /user/xxx/develop/debug/libdynamic.dylib \
#executable_path/libdynamic.dylib \
/user/xxx/develop/debug/illustration
(the exact old name value to pass to install_name_tool will depend on what it's currently set to, which can be determined using otool -L /user/xxx/develop/debug/illustration).
One way to avoid this nonsense (and the way I do it myself) is to use the -install_name linker option:
$(BINDIR)/libdynamic.dylib: $(OBJS)
$(CXX) -dynamiclib -current_version $(MAJOR_MINOR_VERSION) \
-compatibility_version $(MAJOR_MINOR_VERSION) \
-install_name #executable_path/libdynamic.dylib \
$(LDFLAGS) -o $# $(OBJS) $(LIBS)
(Makefile fragment taken from here).
Related
Whenever I compile code using g++, I've noticed that when I run the binary repeatedly, it runs significantly slower than when I compile with clang++.
test.cpp
#include <iostream>
int main() {
std::cout << "Hello World!" << '\n';
}
script.sh
for ((i=0; i<2000; ++i)); do
./a.out
done
Compiling using g++:
g++-11 -O2 test.cpp
time bash script.sh -> 10.32s user 5.37s system 88% cpu 17.751 total
Compiling using clang++:
clang++ -O2 test.cpp
time bash script.sh -> 1.42s user 1.50s system 69% cpu 4.223 total
This is extremely annoying as I need to use g++, but I also need to speed up the binary to make it easier to stress test my code, so an explanation or fix would be welcome.
Note: GCC (11.3, via homebrew), clang (13.1, apple/homebrew (both seem to be the same))
this problem doesn't apply to gcc, only g++
It turns out that this is because g++ links the executable to libstdc++ by default.
The example can be reduced to
// test.cpp
int main() {}
With linking and loading libstdc++:
❯ g++ test.cpp && otool -L a.out
a.out:
/opt/homebrew/opt/gcc/lib/gcc/11/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.29.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
❯ ls -lh /opt/homebrew/opt/gcc/lib/gcc/11/libstdc++.6.dylib
-rw-r--r-- 1 vainman wheel 2.3M Jul 4 01:59 /opt/homebrew/opt/gcc/lib/gcc/11/libstdc++.6.dylib
❯ time bash script.sh
bash script.sh 6.27s user 3.58s system 94% cpu 10.468 total
Without linking and loading libstdc++:
❯ g++ -nodefaultlibs test.cpp -lSystem && otool -L a.out
a.out:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
❯ time bash script.sh
bash script.sh 0.35s user 0.96s system 72% cpu 1.804 total
clang++ also tries linking to /usr/lib/libc++.1.dylib but the file doesn't seem exists.
❯ clang++ test.cpp && otool -L a.out
a.out:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
❯ ls /usr/lib/libc++.1.dylib
ls: /usr/lib/libc++.1.dylib: No such file or directory
Update: Found macOS Big Sur 11.0.1 Release Notes:
New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)
I am trying to link my program (writing it with vim) with SFML. I have my src folder, which contains my code, and the SFML libraries are located at /opt/local/lib. This is the command I am using to compile my code:
g++ src/main.cpp -L/opt/local/lib -lsfml-graphics.2.5 -lsfml-network.2.5 -lsfml-system.2.5 -lsfml-audio.2.5 -lsfml-window.2.5
The code compiles, however, when running the executable I get this error:
dyld: Library not loaded: #rpath/../Frameworks/freetype.framework/Versions/A/freetype
Referenced from: /opt/local/lib/libsfml-graphics.2.5.dylib
Reason: image not found
This is strange, because otool -L a.out tells me that the dylibs are in the correct place:
/opt/local/lib/libsfml-graphics.2.5.dylib (compatibility version 2.5.0, current version 2.5.1)
/opt/local/lib/libsfml-network.2.5.dylib (compatibility version 2.5.0, current version 2.5.1)
/opt/local/lib/libsfml-system.2.5.dylib (compatibility version 2.5.0, current version 2.5.1)
/opt/local/lib/libsfml-audio.2.5.dylib (compatibility version 2.5.0, current version 2.5.1)
/opt/local/lib/libsfml-window.2.5.dylib (compatibility version 2.5.0, current version 2.5.1)
These paths are the correct paths, and #rpath is not listed anywhere in these paths, but the error still says that there is a problem with a dylib with #rpath in its path, which is very weird. Why is this happening and how can I fix it?
Fixed! Turns out that I didn't add the dependencies to /opt/local/lib.
I have a function (written in Swift) and I would like to get the LLVM IR for the function PLUS any dependencies so that I can run the resulting LLVM IR in a fully self-contained environment.
As an example, consider the following function:
func plus(a: Int, b: Int) ->Int {
return a + b
}
plus(5, 7)
I can pass the emit-ir option to swiftc, however, the resulting LLVM IR contains external calls and the resulting IR cannot be run using lli (the error is shown below).
LLVM ERROR: Program used external function '__TFSsa6C_ARGVGVSs20UnsafeMutablePointerGS_VSs4Int8__' which could not be resolved!
Is there any way of grabbing the IR for these external functions so that I can use lli to run the program?
You need to teach the lli about dependencies of the binary.
Here is how to do so.
Let's say there is a "hello world" program:
// main.swift
print("hello")
Compile it to LLVM Bitcode and to a normal executable:
> swiftc main.swift -o hello
> swiftc -emit-bc main.swift -o hello.bc
If you run the main.bc via lli as is, then you will have a similar error to the one you saw with your program.
To learn about dependencies you can use otool on macOS and ldd on Linux:
> otool -L /path/to/executbale
> ldd /path/to/executbale
Here are dependencies for the "hello world" program:
> otool -L ./hello
./hello:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1450.15.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
#rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 900.0.74)
#rpath/libswiftSwiftOnoneSupport.dylib (compatibility version 1.0.0, current version 900.0.74)
In this case, we need to pass libswiftSwiftOnoneSupport.dylib and libswiftCore.dylib to lli sing -load option.
On my machine these libraries live in this directory (I used find to find them):
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx
Finally, here is how you can run your program:
> lli \
-load=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/libswiftCore.dylib \
-load=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/libswiftSwiftOnoneSupport.dylib \
hello.bc
Also, note the order of arguments: it is important that the bitcode file goes last.
Is it possible, with both clang and gcc, in a portable way to not link libstdc++ or libc++, but still link libc and use all the features of C++ (well, only classes).
-nodefaultlibs doesn't seem to work after my first test (tested on OS X), it does not link libstdc++, but it also doesn't link with libSystem, which is required.
The best, and most portable solution is, to just not link any default libraries, and link everything manually.
Adding:
-nodefaultlibs -lc
will not link anything, and afterwards just link libc. Now you've got C with Classes.
You can verify that with either otool -L (on OS X) or ldd (on Linux).
On OSX the output now is:
$ otool -L ./test
test:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
instead of
$ otool -L ./test
./test:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
I am trying to run my C++ program on other Mac OSX machines which may have an older copy of libstdc++, but have all the other tools. I tried to follow this approach, also mentioned in this SO question, even though it discusses a linux setup. I have small program try.cpp:
#include <iostream>
int main() {
int a = 10;
std::cout << a << '\n';
return 1;
}
Obviously, if I just compile it, I get
$ /usr/bin/g++ try.cpp
$ otool -L a.out
a.out:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
I understand the dependency on libSystem.B.dylib, and we can leave that aside. To try to get rid of libstdc++, I try this:
$ /usr/bin/g++ try.cpp /usr/lib/libstdc++-static.a
$ otool -L a.out
a.out:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
So, I try
$ ln /usr/lib/libstdc++-static.a .
$ /usr/bin/g++ try.cpp -L.
$ otool -L a.out
a.out:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
or,
$ /usr/bin/g++ try.cpp -L. -lstdc++-static
$ otool -L a.out
a.out:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
Finally, this works:
$ /usr/bin/gcc try.cpp -L. -lstdc++-static
$ otool -L a.out
a.out:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
Is this alright? (To use gcc to link C++ programs with libstdc++). I've heard somewhere that g++ is actually a script that uses gcc and libstdc++ to compile C++ programs. If that is the case, and we use it correctly, it should be ok.
However, I am actually using the macport compiler and a more complicated program, for which gcc generates some warnings, while it is C++ compliant. Something to the effect of:
ld: warning: std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() has different visibility (hidden) in /opt/local/lib/gcc44/libstdc++.a(sstream-inst.o) and (default) in /var/folders/2u/2uLPtE+3HMi-BQIEfFVbSE+++TU/-Tmp-//ccoE2rqh.o
This suggests that we shouldnt be using gcc for c++ compilations. So to sum up, the questions are:
How to link libstdc++ statically
If g++ doesn't do it, is it ok to use gcc and supply the libstdc++ manually? Then why the visibility warnings?
If neither of the two approaches work because of the visibility problems in the compiled libraries, why not use libstdc++ source files (sstream.h, list.h, vector.c) etc and just include them in the compilation. Even though this will make the compilation slow, it might be useful for certain applications. It might even lead to better optimization!
It sounds like you just want to target earlier Mac OS X versions, which can be done without statically linking with libstdc++. I think the GCC that ships with Xcode targets the host environment by default. However, it can handle a special flag called -mmacosx-version-min to change the target environment. If you provide this with the target OS X version number then it will automatically create binaries compatible with that version of Mac OS X.
#include <iostream>
int main(void)
{
std::cout << "Hello world!" << std::endl;
return 0;
}
Compile like this:
g++ -mmacosx-version-min=10.4 test.cpp
I compiled this program twice, once with the flag and once without, and then I copied both binaries to a Mac running 10.4. The one compiled with the flag executed properly, however the one compiled without the flag said “Bad CPU type in executable” (despite the fact that it was compiled on an identical machine just running a later version of OS X).
Some of the headers have macro guards that prevent you from using functions/classes introduced in 10.5 or 10.6 if you have specified 10.4 as a minimum target (I'm not sure about C++ headers, but the Cocoa, Foundation, AppKit etc. framework headers definitely do).
This is a stretch for my knowledge but I see few responses here so!
GCC is a compiler driver that will also drive the linker. g++ to my understanding is more of just a compiler. So to get G++ to build properly I believe you need to build the object files and link them manually. Of the top of my head I can't say how to do this as I'm IDE brain damaged at the moment.
As to the error you have seen that might be due to the wrong files being linked in. I'm on my iPhone right now so I'm not about to dechiper the error message you printed. I'm not a fan at all of MacPorts so don't be surprised that, that installation is screwed up. First though make sure you are using the MacPorts libs with the MacPorts compiler.
In the end I have no doubt that you can do what you want to do. You will need to however start reading Make files and more of the documentation of the GCC tool set. Focus on building and linking files into programs. You might want to find a small open source program tha builds nicely on a mac and look at the Make files there.
Of course finding a good C++ based project to learn from is not easy. I would however reccomend installing LLVM & CLang especially considering the new rev is suppose to be C++ ready. Obviously a different set of tools but CLang may resolve your issues or at least give you better debugging info. Maybe somebody can chime in with an opensource C++ project with simple clean make files. The closest I've seen lately is a project called HeeksCAD.
In the end when building anything non trivial you end up needing more than just GCC. A lot of that is taken care of with IDEs these days, however I'm not certain if XCode can be properly configured to do what you want.