macOS Boost libraries on OS X

[lloyddean]

Well, I had to modify it for the version of Xcode (xcode_3.2.3_and_ios_sdk_4.0.1.dmg) I've got installed, after which only the Simulator build completed correctly.

I was able to compile and link against the build of simulator static libraries; the test program compiled, linked and ran.

I've since deleted and reinstalled the latest Xcode release just in case something was left behind from one of the many preview versions that had been previously installed.

It looks like I won't get any further than that today. But I'll let you know what I come up with in the next couple of days.

 

[fafonso]

Need a little help

Hi I'm new here and I've a problem slightly different with boost. I've installed it by macports, but I'm using Eclipse. I already had the include and lib folders to the include files and lib paths of Eclipse, however I can not compile the program

I hope someone can help me.

Thanks
Fábio

 

[lloyddean]

What do you mean by "... I can not compile the program"?
What program?
What error messages if any?
What computer language are you compiling for?
What do you plan to do with this program once it's completed?
Do you intend to distribute to others?

I have more questions if you have answers.

 

[fafonso]

I'm a master degree student and I'm building a prototype to efficiently compute similarity searches over trajectories.

The program is only an example of the use of boost to make directories independently from the OS:

#include <iostream>
#include <string>
#include <cstdlib>
#include <boost/filesystem/operations.hpp>
#include <boost/filesystem/fstream.hpp>

using namespace std;
using namespace boost::filesystem;

int main(int argc, char** argv) {

   // Parameter checking...

   try {
      path p = complete(path(argv[1], native));
      create_directory(p);
   }
   catch (exception& e) {
      cerr << e.what( ) << endl;
   }

  return(EXIT_SUCCESS);
}

When I compile this the following errors occurs:

Building target: lixo
Invoking: MacOS X C++ Linker
g++ -L/opt/local/lib -o "lixo"  ./src/lixo.o   
Undefined symbols:
  "boost::system::system_category()", referenced from:
      __static_initialization_and_destruction_0(int, int)in lixo.o
  "boost::system::generic_category()", referenced from:
      __static_initialization_and_destruction_0(int, int)in lixo.o
      __static_initialization_and_destruction_0(int, int)in lixo.o
  "boost::filesystem2::detail::create_directory_api(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)", referenced from:
      boost::enable_if<boost::filesystem2::is_basic_path<boost::filesystem2::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem2::path_traits> >, bool>::type boost::filesystem2::create_directory<boost::filesystem2::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem2::path_traits> >(boost::filesystem2::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem2::path_traits> const&)in lixo.o
  "boost::filesystem2::detail::get_current_path_api(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)", referenced from:
      boost::filesystem2::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem2::path_traits> boost::filesystem2::current_path<boost::filesystem2::basic_path<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::filesystem2::path_traits> >()in lixo.o
  "boost::filesystem2::native(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)", referenced from:
      _main in lixo.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [lixo] Error 1

The language is C++

Hope to have answered all your questions

 

[lloyddean]

I had removed my MacPorts build of boost and am in the process of reinstalling it so can't give you a proper answer but it looks like you haven't specified what boost library to link against. It should be something along the lines of:

-lboost_filesystem -llboost_system

added to your invocation of gcc.

 

[lloyddean]

gcc lixo.mm -I/opt/local/include -L/opt/local/lib -lboost_filesystem -lboost_system -o "lixo"

 

[fafonso]

Thank you a lot, it is now working

 

[lloyddean]

Congratulations!

Please be aware, thus some of the (unanswered) questions above, that the Mac linker will always prefer shared dynamic libraries, when they exist, over static libraries.

What this means is even though you may explicitly specify a static library to link against if a shared library exists it will be used instead. This has implications in that if you plan to distribute your application to systems which don't have Mac Ports and Boost installed the application will fail to find, load and link to the shard dynamic library that doesn't exist.

 

[fafonso]

thanks a lot for the warning, I will be carful with that

 

[aaptuster]

Not able to link , although the path is to the right location of library files.

Hi,

I am new to Mac So, I need the help of Mac Pros over here.

I am using Xcode (3.1), and I am trying to add boost library to it. I have completed the steps of building the library using bjam tool and I find that the right path is being pointed to during build, however, compilation of code goes fine and linking fails.

Details:

I am using boost threads in my minor example code.

Error thrown and command:

Ld build/Debug/trial normal x86_64
cd /Users/siddharthshankaran/Documents/trial
setenv MACOSX_DEPLOYMENT_TARGET 10.6
/Developer/usr/bin/g++-4.2 -arch x86_64 -isysroot /Developer/SDKs/MacOSX10.6.sdk -L/Users/siddharthshankaran/Documents/trial/build/Debug -L/Users/siddharthshankaran/Library/boost_1_43_0/stage/lib -F/Users/siddharthshankaran/Documents/trial/build/Debug -filelist /Users/siddharthshankaran/Documents/trial/build/trial.build/Debug/trial.build/Objects-normal/x86_64/trial.LinkFileList -mmacosx-version-min=10.6 -o /Users/siddharthshankaran/Documents/trial/build/Debug/trial




Undefined symbols:
"typeinfo for boost::detail::thread_data_base", referenced from:
typeinfo for boost::detail::thread_data<void (*)()>in main.o
"boost::thread::start_thread()", referenced from:
boost::thread::thread<void (*)()>(void (*)(), boost::disable_if<boost::is_convertible<void (*&)(), boost::detail::thread_move_t<void (*)()> >, boost::thread::dummy*>::type)in main.o
"boost::detail::thread_data_base::~thread_data_base()", referenced from:
boost::detail::thread_data<void (*)()>::~thread_data()in main.o
boost::detail::thread_data<void (*)()>::~thread_data()in main.o
"vtable for boost::detail::thread_data_base", referenced from:
boost::detail::thread_data_base::thread_data_base()in main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status



structure of my boost library:

bash-3.2$ ls *thread*
libboost_thread-xgcc42-mt-1_43.a libboost_thread-xgcc42-mt-s.a
libboost_thread-xgcc42-mt-1_43.dylib libboost_thread-xgcc42-mt-sd-1_43.a
libboost_thread-xgcc42-mt-d-1_43.a libboost_thread-xgcc42-mt-sd.a
libboost_thread-xgcc42-mt-d-1_43.dylib libboost_thread-xgcc42-mt.a
libboost_thread-xgcc42-mt-d.a libboost_thread-xgcc42-mt.dylib
libboost_thread-xgcc42-mt-d.dylib libboost_thread.a
libboost_thread-xgcc42-mt-s-1_43.a libboost_thread.dylib
bash-3.2$ pwd
/Users/siddharthshankaran/Library/boost_1_43_0/stage/lib


What possibly could be wrong now? Compilation succeed and its only the linking part that's failing. Please help in this.

Or else, suggest me some way to redo it form scratch in a way that it would work! Thanks in advance!!

 

[Golker]

OK, I figured out how to solve part of my problem.

Using command line g++, there apparently IS no way to set a "path" except to actually explicitly declare it on the command line when compiling, using the "-I" switch.

In my case, I installed Boost using MacPorts, and it ended up in
/opt/local/var/macports/software/boost/1.37.0_0+darwin_9/opt/local/include/boost

However, putting #include<that/entire/11-step/path> into my program did not work, and using
g++ -I that/whole/path/to/boost gave a "File not found" error.

Here's the trick: back up one directory on the -I path statement, like so:
g++ -I /opt/local/var/macports/software/boost/1.37.0_0+darwin_9/opt/local/include/

(note that it looks the same, except I didn't type "boost" on the end)

My first.cpp test file (above) then compiled and ran without complaint. It works to name the directory CONTAINING the boost directory, but not the boost directory itself.

Naming an -I "starting path" for g++ means it will start looking recursively down from that starting path. Since the various boost headers all name their dependencies by saying "boost/whatever", that means if I name "boost" as the starting path, g++ is therefore directed to look in "boost/boost/whatever" and that generates the "File not found" error.

I then did this in my home directory:

ln -s /opt/local/var/macports/software/boost/1.37.0_0+darwin_9/opt/local/include/ boost

This made a symbolic link to that long directory path named simply "boost". That way, I was able to then do this:
g++ -I boost first.cpp -o first
and it compiled just fine. I moved the source file down into a sub-directory, and typed
g++ -I ../boost first.cpp -o first
and that compiled too, because g++ was able to follow the path to the symbolic link, which it could then follow to the actual boost directory.

That must seem like the stupidest most obvious thing in the world to most of you fellows. Hope that helps someone else like me sometime.

Thanks!
John

I know this is a stupidly old topic, but I just wanted to thank you for this answer
It really helped me. I also miss the option of not having to put "boost" in the g++ command line, but, at least it's working. Just dont get why people from Boost.org dont make a keener installer for Mac OS X. Linux's installer works like a charm, and havent tried Windows', but I assume it's just as easy, so why not Mac too?

Anyway, thanks again!

 

[mghiggins]

Boost (via MacPort) build problem

I installed boost 1.47 using MacPort and want to use it from XCode 4.

I'm running into problems though and don't understand what the error messages imply; maybe someone here can help...

I did the usual boost install using MacPort, which installed headers in /opt/local/include and libraries in /opt/local/lib.

I added /opt/local/include/** (ie recursive) into my Header Search Path for the project. If I then try to build *any* code - even code that does not #include any boost libraries - it fails to build in the standard c++locale.h file. ie not a link error (and added /opt/local/lib/** into the library search path doesn't affect things). The error message is:

No member named 'vsnprintf' in namespace 'std'

The same build error appears 15 times in that same file. No other build errors.

I haven't seen any other examples of this error associated with boost when I google around, so I'm a bit lost! Any help appreciated.

 

[mghiggins]

Re: Boost (via MacPort) build problem (FIXED)

I installed boost 1.47 using MacPort and want to use it from XCode 4.

I'm running into problems though and don't understand what the error messages imply; maybe someone here can help...

I did the usual boost install using MacPort, which installed headers in /opt/local/include and libraries in /opt/local/lib.

I added /opt/local/include/** (ie recursive) into my Header Search Path for the project. If I then try to build *any* code - even code that does not #include any boost libraries - it fails to build in the standard c++locale.h file. ie not a link error (and added /opt/local/lib/** into the library search path doesn't affect things). The error message is:

No member named 'vsnprintf' in namespace 'std'

The same build error appears 15 times in that same file. No other build errors.

I haven't seen any other examples of this error associated with boost when I google around, so I'm a bit lost! Any help appreciated.

Sorted it out - in the header search path I just need to click *off* Recursive. Then it all works. Surprising though since I don't see how, if I include /opt/local/include, it can see the headers in the boost directory that's inside include... anyways, that's the fix.