CODEWITHSUNDEEP
c++cosx-lion
Dan
Dan

Reputation: 1745

Compilation errors for libplist on OS X Lion: string.h not found

I'm trying to compile Clementine for OS X. Midway through the process of compiling dependencies, during libplist-1.3, I'm getting an error that the compiler cannot find string.h, assert.h, etc. Then a slew of errors follow.

I'm unsure why this would be the case. I'm not very experienced in working with larger C projects and would appreciate any direction in finding out why this is happening. I've definitely installed the Xcode command line tools and made sure they're up to date. Also, the standard files are in /usr/include.

Output after running make per build instructions:

cd libplist-1.3/build && PKG_CONFIG_PATH=/Users/dan/projects/sandbox/target/lib/pkgconfig cmake .. -DCMAKE_OSX_ARCHITECTURES=x86_64 -DCMAKE_INSTALL_PREFIX=/Users/dan/projects/sandbox/target -DQT_HEADERS_DIR=/Users/dan/projects/sandbox/target/include/ -DQT_LIBRARY_DIR=/Users/dan/projects/sandbox/target/bin -DENABLE_PYTHON=OFF
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    QT_HEADERS_DIR
    QT_LIBRARY_DIR


-- Build files have been written to: /Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/build
cd libplist-1.3/build && PATH=/Users/dan/projects/sandbox/target/bin:$PATH make -j2
[ 12%] [ 12%] Building C object src/CMakeFiles/plist.dir/plist.c.o
Building C object src/CMakeFiles/plist.dir/bplist.c.o
/Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/src/plist.c:23:20: error: string.h: No such file or directory
/Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/src/plist.c:24:20: error: assert.h: No such file or directory
In file included from /Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/src/plist.h:25,
                 from /Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/src/plist.c:25:
/Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/include/plist/plist.h:48:20: error: stdint.h: No such file or directory
/Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/include/plist/plist.h:52:23: error: sys/types.h: No such file or directory
In file included from /Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/src/plist.h:25,
                 from /Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/src/plist.c:25:
/Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/include/plist/plist.h:128: error: expected ‘)’ before ‘val’
/Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/include/plist/plist.h:137: error: expected ‘)’ before ‘val’
/Users/dan/projects/sandbox/clementine-dep/macosx/libplist-1.3/include/plist/plist.h:156: error: expected declaration specifiers or ‘...’ before ‘uint64_t’

.. and many more

Update:

When removing the -j2 flag, libplist builds successfully. Now I am getting a new error down the line:

Scanning dependencies of target libproxy
[ 54%] Building CXX object libproxy/CMakeFiles/libproxy.dir/extension_config.cpp.o
[ 57%] Building CXX object libproxy/CMakeFiles/libproxy.dir/extension_pacrunner.cpp.o
[ 60%] Building CXX object libproxy/CMakeFiles/libproxy.dir/extension_wpad.cpp.o
[ 63%] Building CXX object libproxy/CMakeFiles/libproxy.dir/proxy.cpp.o
/Users/dan/projects/sandbox/clementine-deps/macosx/libproxy-0.4.7/libproxy/proxy.cpp:433:15: error: use of undeclared identifier
      'strdup'; did you mean 'strcmp'?

Upvotes: 1

Views: 1252

Answers (1)

Mosby
Mosby

Reputation: 1341

Partially copied from the comments:

Try compiling with make instead of make -j 2. Sometimes the compile order can get screwed up and this is explicitly mentioned in the package site you linked to.

As for the issues with strdup, the function is declared in string.h for C and cstring for C++. If the package is built correctly and doesn't create duplicate headers or try to use headers from non-standard locations, then starting from a completely fresh build might fix your problem.

If that doesn't work, you need to go through the cmake logs and look for directories in the include paths which may have string.h or cstring in them and might get used instead the default one. If this is the case, you should definitely notify the maintainer and figure out if simply removing these files or include path is an appropriate fix.

Beyond that I think you'll have to get in touch with the package maintainer through their site.

Good luck!

Upvotes: 1

Related Questions