I'm trying to compile pulseaudio on Mac OS X, however by default I get lots of errors about not finding standard files like inttypes.h, errno.h or stdio.h. Putting -isystem/usr/include in CPPFLAGS fixes those errors, but then later on I get fatal error: 'CoreServices/CoreServices.h' file not found.
I've tried also adding -framework CoreServices and/or
-I/System/Library/Frameworks/CoreServices.framework/Headers but neither work.
What's the proper way of making the compiler find it?
I think I'm using clang, gcc produces even more errors.
You are on the right track, those are the framework and include flags but if you use the correct configuration options you will find even the system includes are picked up properly.
The Makefiles will attempt to set the framework appropriately based on the --with-mac-sysroot and --with-mac-version-min attributes.
Example configuration option to specify the SDK location:
--with-mac-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/
--with-mac-version-min=10.7
If you are building on Mountain lion (10.8) you still need to use the 10.7 minimum compatibility as there are headers missing in the 10.8 SDK which PulseAudio makes reference to.
You can pass the configure options to the autogen.sh which will run configure once autoconf has completed. You can try the following command which has been tested on the master branch:
./autogen.sh --prefix=/usr/local --disable-jack --disable-hal --disable-bluez --disable-avahi --with-mac-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/ --with-mac-version-min=10.7 --disable-dbus
If you get m4 macro errors copy the m4 macros from aclocal into the m4 sub-directory and try again.
There are a few other problems but these are bound to be cleared up may date quickly. Adding it here as it may help someone trying to get this built.
error: Multiprocessing.h cannot be found:
This has been deprecated in 10.7 but the headers are still included it CoreServices and will build just change the include instruction in the file src/pulsecore/semaphore-osx.c.
-#include <Multiprocessing.h>
+#include <CoreServices/CoreServices.h>
error: ‘lt_PROGRAM_LTX_preloaded_symbols’ undeclared.
This may be a problem compiling src/daemon/dumpmodules.c and can be fixed by declaring the external macro.
extern const lt_dlsymlist lt_preloaded_symbols[];
error: gdbm.h: No such file or directory
For some reason the default include dir is not considered by the compiler and you can add the path to the src/Makefile look for and set the variable GDBM_CFLAGS.
GDBM_CFLAGS=-I/usr/local/include
nJoy!
Related
How can I link libxml on MinGW when using an omnetpp shell?
I am using omnetpp on a windows 10 machine.
My problem happens when I am trying to install the 3rd party package from here
I think that there is a problem in the Makefile failing to locate the libxml library
Following Rudi's answer (following the question) I changed the Makefile libxml path to I/mingw64/include/libxml2 but I still
get a undefined reference to 'xmlFunctionName' error (for many function names)
I tried to isolate the problem and to compile a sample of code from libxml2
Following the compilation guide: using gcc `xml2-config --cflags --libs` -o tree2 tree2.c
I got a fatal error: 'libxml/parser.h' file not found
When I replaced xml2-config --cflags --libs with -I/mingw64/include/libxml2
I got the same error as before undefined reference to 'xmlFunctionName'
what can I do to resolve that issue?
To this specific problem: libxml2 is actually already present as OMNET 5.x also uses it. All dependencies and tools are available in the tools/win64/mingw64 directory. The problem is that (for unknown reasons) the include file of the include/libxml2/libxml folder. The configure script correctly detects this and makes it available in the Makefile.inc as XML_CFLAGS= = -I/mingw64/include/libxml2
This must be added to the compiler flags for each file where you want to use the XML parser. (the library files are in the /mingw64/lib folder) so those are detected and can be used without additional config.
Generally, third party libraries should be available in the /mingw64/include and /mingw64/lib folders. You can either copy them manually there or try to install it with the mingw package manager (however that will most likely ruin your omnet installation as mingw64 is not particularly consistent and it is a rolling release - i.e. this is highly not recommended).
I am trying to build gcc 4.3-74 for powerpc using cross compilation. I used the following configure command to configure the make file.
./configure --build=i686-pc-linux-gnu --target=powerpc-linux
--host=powerpc-linux --with-gmp=/xxx/include --with-gmp-include=/xxx/include --with-gmp-lib=/xxx/lib
configuration is done successfully, but when I do a make, it failed with the following message
In file included from ../.././libiberty/floatformat.c:31:0:
/usr/include/string.h:548:5: error: unknown type name ‘__locale_t’
__locale_t __loc)
^
/usr/include/string.h:552:18: error: unknown type name ‘__locale_t’
It seems like it is not fetching the right header file for powerpc.
I had similar issue with building binutils when I did configure without option --host=powerpc-linux. As soon as I used an option --host=powerpc-linux in configure, the same error is gone in case of binutils.
In my case, it was using some pretty old compiler for compilation. This old compiler was set to PATH variable in my user profile. Hence when I was executing gcc, it was executing old one and it resulted in this error.
I removed PATH setting in my user profile. Now when I run gcc, it is executing the latest gcc. The problem is solved now.
I am trying to build the tests for rapidjson 0.11 (http://code.google.com/p/rapidjson/) on Mac OS X . It includes three projects: gtest (builds fine), unittest (build fails), and perftest (build fails), and when building make error out with Error 1 and Error 2.
The compiler output shows the following errors for both unittest and perftest which causes make to fail:
../../include/rapidjson/reader.h: In function ‘const char* rapidjson::SkipWhitespace_SIMD(const char*)’:
../../include/rapidjson/reader.h:116: error: ‘_SIDD_UBYTE_OPS’ was not declared in this scope
../../include/rapidjson/reader.h:116: error: ‘_SIDD_CMP_EQUAL_ANY’ was not declared in this scope
../../include/rapidjson/reader.h:116: error: ‘_SIDD_BIT_MASK’ was not declared in this scope
../../include/rapidjson/reader.h:116: error: ‘_SIDD_NEGATIVE_POLARITY’ was not declared in this scope
These pre-processor constants are related to SSE4 instructions. rapidjson can use SSE2 or SSE4.2 to speed it up, and it defaults to using SSE4.2 when building.
The makefile includes the -msse4.2 compiler switch to enable SSE4.2 support, and looking through the header files reveal that on OS X, both SSE4_1 and SSE4_2 pre-processor constants need to be defined for the SIDD... constants to be defined. For some reason, these SIDD... constants aren't being defined.
Further research showed that the -msse4 switch enables support for both SSE4.1 and SSE4.2, so I tried chaning the switch to -msse4, but it still errors out.
Not sure if the -msse4.2 switch automatically defines SSE4_2 , but I tried manually defining it, and sill no luck.
NOTE: If you want to try building it yourself on Mac, you will need to download a different premake script file, as the included one doesn't work. You can download the corrected script from the attachment on the second post here https://code.google.com/p/rapidjson/issues/detail?id=54
Any ideas on how to get it building successfully on OS X ?
Short answer - I had an older version of gcc (4.2) which didn't support -msse4.2 flag (it was introduced in gcc 4.3).
After upgrading to the latest version of gcc, the above issue disappeared:
Check which version of gcc is active with by opening a terminal and
running gcc -v
Download MacProst installer for your version of OS X from http://www.macports.org/install.php and run installer (easy way to upgrade GCC version)
Open new terminal window (must be new as PATH environment var is updated after MacPorts
install)
Check which versions of gcc you already have installed with port select --list gcc (NOTE: you probably won't have some of the later versions installed already. See next step)
Install latest version of gcc (gcc47 at the moment) with sudo port install gcc47 (this will take a while to download)
Run port select --list gcc again and you should see the new version in the list (eg. mp-gcc47)
Select this latest version as active gcc version with sudo port select gcc mp-gcc47
Run gcc -v again to check the latest version is active
With the compiler sorted, the first attempt to build rapidjson for release32 gave me errors about the limits header file due to __int128 not being defined for 32-bit builds`. Gnu's official position is that you need to roll your own. See answers at following link for more info:
Compiling 32bit binary: expected unqualified-id before '__int128'
Building for release64 or debug64 solved this issue, but it still failed to build due some warnings about casting away qualifiers in test/unittest/readertest.cpp:187:4. As the make file included the compiler flag -Werror=cast-qual, these warnings were treated as errors. Removing this flag in both unittest and perftest makefiles solved this issue (not ideal solution but I just wanted to get it building).
There were still linker warnings as the /usr/lib64 folder didn't exist, and the makefiles included the flag -L/usr/lib64, but the build was still successful.
SUCCESS - Both unittest_release_x64_gmake and perftest_release_x64_gmake ran without problems!
NOTE: rapidjson build instructions are included in the readme file in the ZIP archive.
I have another OSX application problem. I want to bundle in my final application several dylibs, all of them needed by the application and by other dylibs.
I change its references using the install_name_tool, but some of the libraries couldn't be changed properly, having this error:
install_name_tool: changing install names or rpaths can't be redone for: aLibrary.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
So I added the headerpad_max_install_names option flag on the linker flags of the xcode project (Project Properties-Build Settings-Linking-Other Linker Flags). Also I verified in the build log, if the option flag was included, and the option flag was included properly.
But still having the same error in the last dylibs.
Is there any way to bundle all the libraries needed in a unique Framework? Or am I doing something wrong in the building process?
Hope I'm clear with the main problem.
Thanks!
I had this same problem, using C++ and Code::Blocks, and I fixed it by switching from g++ to clang++
I've set LIBRARY_SEARCH_PATHS to /opt/local/lib, and verified that the library in question is there (I'm linking to GLEW):
$ls /opt/local/lib
libGLEW.1.5.1.dylib libfreetype.a libz.a
libGLEW.1.5.dylib libfreetype.dylib libz.dylib
libGLEW.a libfreetype.la pkgconfig
libGLEW.dylib libz.1.2.3.dylib
libfreetype.6.dylib libz.1.dylib
but Xcode gives me the linker error
library not found for -lGLEW
I'm generating the Xcode project with CMake, so I don't want to explicitly modify the Xcode project (if someone suggests adding it as a framework, or something like that). Xcode recognizes USER_HEADER_SEARCH_PATHS fine (as in this question); why doesn't it work here?
Perhaps adding something like this to your CMakeLists.txt?
find_library(GLEW_LIB GLEW /opt/local/lib)
if(NOT ${GLEW_LIB})
message(FATAL_ERROR "Could not find GLEW")
endif()
target_link_libraries(myprogram ${GLEW_LIB} ...)
Where myprogram is the name of the target executable that needs to link with the library. You would replace the ... with the other libraries you are using on that executable.
This way CMake would handle the library path details for you.
Xcode works on potentially multiple SDK's, so whenever your define these kinds of things (like HEADER_SEARCH_PATHS or LIBRARY_SEARCH_PATHS) the current SDK root is prepended to the actual path that's getting passed to the linker.
So, one way to make this work would be to add your directory to the SDK. For example, assuming you're building with the Mac OS X 10.5 sdk, you could add your opt dir:
ln -s /opt /Developer/SDKs/MacOSX10.5.sdk/opt
Your library would now be found on your system.
If you don't want to do this, then you will have to look at CMake and find out how to get it to generate a library requirement for your actual library (I don't know anything about CMake, so I can't help you there). This is also why you see a difference between USER_HEADER_SEARCH_PATHS and HEADER_SEARCH_PATHS re your other question.
As another option, you could also specify this path with the OTHER_LDFLAGS build variable:
OTHER_LDFLAGS=-L/opt/local/lib
This would cause the linker to search /opt/local/lib as well as its standard paths and wouldn't require you to generate a different project file.