I'm trying to compile ImageMagick (in particular Magick++) with clang++ and libc++. Therefore I need to pass -stdlib=libc++ to both compiler and linker.
While CXXFLAGS="-stdlib=libc++" works fine for compiling, LDFLAGS="-stdlib=libc++" seems to only affect the C linker.
How to correctly tell ./configure or make to use this flag when linking C++ libraries?
Use both — CXXFLAGS for the C++ compiler and LDFLAGS for the linker:
./configure CXXFLAGS="-O2 -g -stdlib=libc++" LDFLAGS="-stdlib=libc++"
You could try:
LDFLAGS="-Wl,-stdlib=libc++"
Related
With the new XCode/Swift release comes the ability to use binary dependencies. This seems to me to be an ideal time to create an SPM package for FFMpeg.
However, while I've spent the last year learning to code i Swift, I'm actually not all that familiar with how to build libraries, especially those as complex as FFmpeg with all the configurable libraries and third-party dependencies.
There's kewlbear's iOS build scripts, but these are for iOS/tvOS and ideally an FFMpeg SPM package would be usable for MacOS also. It's also not updated for the newest Xcode and Swift versions.
My personal interest is simply in audio and I don't need a lot of bells and whistles, but I figure the ideal situation would be a full package with the entire source and whatever dependencies it needs, and then when it's used as a package dependency, the compiler will just use the parts it needs.
I guess my question is...how would I ideally compile the ffmpeg code for this purpose. I'm trying to follow the directions for compiling yourself, but I'm stuck at the point of compiling gettext because I'm not sure if I should follow the directions (in the gettext source code) for compiling a fat binary for multiple architectures, and when I try to run:
./configure CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
CPP="gcc -E" CXXCPP="g++ -E"
I get the following error:
checking whether the C compiler works... no configure: error: in
`/Users/nolainecrusher/Downloads/FFMpeg-source/gettext-0.21/gettext-runtime':
configure: error: C compiler cannot create executables See
`config.log' for more details configure: error: ./configure failed for
gettext-runtime
and config.log doesn't really tell me anything useful:
This is what I see at the end of the log:
mkdir_p='$(MKDIR_P)' oldincludedir='/usr/include' pdfdir='${docdir}'
prefix='/usr/local' program_transform_name='s,x,x,' psdir='${docdir}'
sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' subdirs='
gettext-runtime libtextstyle gettext-tools' sysconfdir='${prefix}/etc'
target_alias=''
I feel like maybe I'm going about this the wrong way, but I'm not sure what the right way is.
See the following:
A Swift wrapper package for FFmpeg and
A C wrapper package for FFmpeg
SwiftFFmpeg assumes ffmpeg is installed locally and will link with those libraries. Also, SwiftFFmpeg uses CFFmpeg as a package dependency, and your app can use SwiftFFmpeg as a dependency.
If you want to see a build script for compiling ffmpeg (x86_64 and arm64), check out my own audio player project.
I try to compile several open-source libraries for iOS as shared libraries with bitcode. I've added flag -fembed-bitcode into CFLAGS and LDFLAGS. Compilation completes normally but some of resulting libraries (curl for example) has no bitcode in them (I've checked it with otool -l lib.dylib | grep LLVM).
My investigation shows that flag -fembed-bitcode simply disappears from linker command line when dylib is linking though in Makefile there is direct usage of LDFLAGS in this place. How -fembed-bitcode can be dissapear from LDFLAGS?
The reason for -fembed-bitcode flag disappearing is that library use libtool for linking and it strips unknown flags by default:
When creating a shared library, but not when compiling or creating a
program, libtool drops some flags from the command line provided by
the user. This is done because flags unknown to libtool may interfere
with library creation or require additional support from libtool, and
because omitting flags is usually the conservative choice for a
successful build.
If you encounter flags that you think are useful to pass, as a
work-around you can prepend flags with -Wc, or -Xcompiler to allow
them to be passed through to the compiler driver (see Link mode).
Another possibility is to add flags already to the compiler command at
configure run time:
./configure CC='gcc -m64'
So I've just add -Wc,-fembed-bitcode flag to LDFLAGS in addition to -fembed-bitcode and library compiles with bitcode.
I've tried to compile the simple pthreading code using g++.
To the best of my knowledge, I should use the -lpthread but it cannot make the executable.
Below is the error code (it seems that libpthread doesn't linked):
undefined reference to `pthread_create'
However, interestingly, when I compile with the option -pthread it is correctly compiled and completely working well.
My g++ version is gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2).
the -l option indicates the compiler to link the program with the named library, so -lpthread means to link the pthread library.
-pthread is an option that's required to build
threaded programs in gcc.
-pthread is preferred if available.
I'm trying to compile a very small amount of C source into a library that I can use in XCode for an iOS application.
The files are a single .c file and three header files. I'm very new to C, and no matter what I try I can't seem to get them to compile into a library that supports iOS architectures.
The files depend on the openssl library, and I've got that installed and working fine.
I just need to know the process of compiling these four files into a single library. I've found a plethora of information on the subject online, but I can't decipher which parts are necessary for what I'm trying to do.
I've tried the following:
gcc -fPIC -c main.c
gcc -shared -o mylib.so main.o -lcrypto -lssl
which seems to compile it for x86_64, (I've not tested the resulting file, just checked it's arch).
I've also tried
./configure --disable-shared --enable-utf8 --host=arm-apple-darwin CFLAGS="-arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk" CXXFLAGS="-arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk" LDFLAGS="-L." CC="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc" CXX="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++"
which only gives me errors
checking for arm-apple-darwin-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Users/nathanf/compilec':
configure: error: C compiler cannot create executables
I've been scouring the internet for the last few days trying to figure this out, but it's so convoluted to cross compile just a few files and I'm frustrated so I came here for some input.
Any help would be greatly appreciated.
I want to use the LAPACK library in my fortran code. I am compiling using gfortran and want to call the dgesv function from the lapack library.
I downloaded lapack3.5.0 and built it using Cmake which also tests it. The build for lapack3.5.0 has created the following libraries: libblas.a, liblapack.a, libtmglib.a
I am using a make file to compile my code using gfortran.
How do I use these libraries with gfortran compiler, I get error of dgsev being undefined when I compile. I have added the path to these libraries to the system path.
I have no clue what to do to use external libraries in gfortran.
You have to use -L option of gfortran linker. Using this you will point the compiler to look for libraries in this path.
For example:
gfortran test.f -L/path/to/libs -llapack -lblas
If you have additional libraries you can setup like this
LLIBS = -L/path/to/libs -llapack -lblas
XLIBS = -L/usr/X11R6/lib64 -lX11 -lpthread
GLIBS = -L/usr/X11R6/lib64 -lGLU -lGL -lX11 -lXext -lpthread
OBJS = test.o
gfortran $(OBJS) $(LLIBS) $(XLIBS) $(GLIBS)
There is no need to add anything to system path.