Linking to boost

Finding a dynamic library happens at runtime, not compile time. You have to put the dylib somewhere in a system path in order for the executable to find it. A better idea for MacOS X, is to package the dylib inside the executable bundle and use "installnametool" to tell the executable exactly where the dynamic library is.

frangipane wrote:
I don't have any familiarity with install nametool to actually do anything with it.

And you are building things with boost?

My preference would be to link to the static library, not the dynamic one anyway. I have properly specify the library search path.

This is boost you are talking about - a library so complex it needs its own build system.

This has worked before ( I did an upgrade). What could be wrong?

You built boost from scratch and installed it onto a new OS. This time you have an upgraded OS and you are trying to link against software built under the old OS. In reality, what you are doing is equivalent to trying to compile some old PPC libraries built on 10.4 on a new Intel 10.5 machine.

Boost is a complex library. If you don't have a good understanding of it and the dynamic library system, you aren't going to have much luck with fixing it. I suggest you blow away all custom code you have built and re-build it from scratch on the new system. It should work fine then. If you have installed custom code into system locations, you may need a clean OS install as well. There is no easy answer that doesn't require either a lot of system knowledge or lots of time to reinstall things.

frangipane wrote:
The boost libraries were built using bjam, as shown in my 1st post, after re-installing XCode (because the upgrade to Snow did not upgrade the SDK from 10.5 to 10.6). There were no errors during that process and the resulting directory structure came out clean with the desired libraries as shown in my 1st post.

But what is inside those libraries? Run "file" on them to make sure they are what you expect they are.

My project is built with XCode. I hope you are not suggesting that this should also be built with some specific boost tool?!

No. Once you get things built properly, you can build applications using boost with anything you want.

I suggest you blow away all custom code you have built and re-build it from scratch on the new system. It should work fine then.

I didn't just do a Clean Targets. I removed all the build files in my project and rebuilt from scratch.

Unfortunately, compiling any software is kind of complex and boost especially so. There is no way to debug it via a forum like this other than to first ask you to track down all of the libraries you are linking together and run "file" on them to find out just what they are. That is your first step. Until you do that, you aren't going to make any progress at all.

There has been some discussion about boost/10.6 here:
http://lists.boost.org/boost-build/2009/10/22545.php

but it's a beyond my technical ability and probably adresses a different objective. All I care about, at this point, is to be a able to link whether, statically (as I used to) or dynamically or under 32bit or 64bits, SDK 10.5 or 10.6. I tried all : only 64 and 32/64-standard has no compile error, for either 10.5 or 10.6, but still has the above runtime error.

You are going to have to take this one step at a time. That is probably why you are having trouble to begin with. It sounds like you never had boost properly installed on your system to begin with and were linking statically just to get it to work without getting into the details.

You are going to have to hold off on the cross-compilation for a bit. First, delete all the code you have, rebuild with your native architecture, and link with the dynamic library. That should always work. It it doesn't, you are wasting your time trying to get it building with a more complicated architecture.

Once that is working, then you can try a universal binary.

If you have installed custom code into system locations, you may need a clean OS install as well.

System code such as library path? Probably not and I guess the bjam build would have complained about it otherwise.

I don't understand your response here. When you build boost, where does it get installed? My guess is somewhere in "/usr/local". That would be good. Does boost have an uninstall? That would be better. If you have an old 32-bit boost installed in /usr/local, you are going to have to clean that out first.

I'm not trying to be mean about this. You just shouldn't base an architecture on software you can't manage. I know that I can't manage boost and that is why I never used it, even when I was a hard-code C++ geek. This is the downside of open-source, if there are problems, you are on your own.

I expect that it will work in 10.6. But you have to take it one step at a time. The first step is making sure all the old boost code is cleaned out and rebuilt. Run "file" on every object file and library involved to make sure it is what you think it is. That alone should be enough to tell you where the problem is.

frangipane wrote:
What do you mean run file?

The "file" program. It will tell you what kind of object code is inside a library or executable file:

[jdaniel@Pele:503] /usr/local/lib $ file libntfs-3g.a
libntfs-3g.a: Mach-O universal binary with 2 architectures
libntfs-3g.a (for architecture i386): current ar archive random library
libntfs-3g.a (for architecture ppc): current ar archive random library

Anyway, the error suggests that the file can't be found, which has nothing to do with what I expect they are. Sorry, I don't get it.

The error you are talking about concerns your attempt to force a link to a static library. You aren't there yet. If you decide, for whatever reason, to link to a static library, you do that only at the end, when everything else is running. If you do it sooner, just to get something working, you wind up in the state you're in now.

I didn't have to get into details : it worked. I don't see what your judgment is based on

It is based on the fact it doesn't work now.

install bjam reported no problem.

That is just the installation of boost. You are trying to link against boost. You may have multiple copies of boost (with multiple architectures) on your system.

What's disquieting is that if I add to the library the statically linked library (*.a), I don't expect a dynamic link error message.

Forcing a link with a static library is not normally done. The default is to use dynamic libraries, if available. Get it working the normal way first. Then get it working the way you want.

You are going to have to hold off on the cross-compilation for a bit.

I wasn't trying to. I was just referring a link that talks about it.

Whether you mean to or not, if you start trying to set SDK or 32 vs. 64 bit, you are doing cross-compilation.

it installs where I tell it to install via a prefix in the install command. It comes out like this:

~/Library/boost_library/boost_1_40_0/include

~/Library/boost_library/boost_1_40_0/lib/
libboost_serialization.a
libboost_serialization.dynlib

As you can see, I have use a release number to specify the path, and in the Project > Build > Library search path I give ~/Library/boost_library/boost_1_40_0/lib/

That is not a good location for a dynamic library. You can make it work using the "install_name_tool" program. The default prefix (/usr/local) would be better.

Thanks, but for now, it's not clear what the steps should be. I've also tried

set DYLD_LIBRARY_PATH=~/Library/boost_library/boost_1_40_0/lib/:$DYLD_LIBRARY_PATH

as suggested in the boost mailing list. I would have thought that it would show up in $env or echo $DYLD_LIBRARY_PATH would show the link, but not.

Those instructions are for Linux. The Mac is a different beast.

I also found a related link here:

http://lists.apple.com/archives/xcode-users/2009/aug/msg00174.html

but haven't made much sense of it yet.

There is good information in that link.

My recommendation is as follows:
1) Build and install boost into the default location. Don't mess with any SDK or 32/64 bit settings.
2) Remove your custom boost path from your application program and build. Everything should work perfectly.

Now, with a working setup, you can work on modifying things to suit your preferences. If you install boost anywhere other than /usr/local, you will have to add a custom boost path to any project that uses boost. You will also have to employ the "install_name_tool" to specify the location of a dynamic library in a non-standard location.

You can, instead, link to a static library if you want. But it would be better to experiment with static linking on a project that already works perfectly to begin with. Once you can reliably create boost applications, and link with static libraries, then you can install a versioned boost in a non-standard location and use it with no problems.

frangipane wrote:
$ file ~/Library/boost library/boost_1_40_0/lib/libboostserialization.a
~/Library/boost library/boost_1_40_0/lib/libboostserialization.a: current ar archive random library
$ file ~/Library/boost library/boost_1_40_0/lib/libboostserialization.dylib
~/Library/boost library/boost_1_40_0/lib/libboostserialization.dylib: Mach-O 64-bit dynamically linked shared library

Perhaps boost isn't build properly after all. That .a file shouldn't be empty. I will try to build it myself, but that won't happen for a few hours.

For all previous releases it wasn't a problem to put the link libraries somewhere in ~/ and I didn't need (or know how to use) install nametool

It won't be now as long as you do it properly. Something is screwed up and you have to find and resolve that before you can more forward.

/usr/local is not visible in XCode > AddToProject which is why I'm reluctant to put the libraries there. What do you suggest here?

/usr/local is always visible. It is part of the system paths.

The instructions were recognized by the shell. How so then?

It is a long story. DYLD LIBRARYPATH might work as long as you always run your software from the command line. But the Mac isn't designed to have everything run from the command line. For that reason, there are better ways to specify where dynamic libraries live. In any event, that is a runtime thing. You aren't there yet.

You mean from XCode > AddToProject open Macintosh HD > System ?! Haven't seent it.

I added /usr/local to Finder > Places but that isn't even visible from XCode > AddToProject !!

No. You don't do anything for /usr/local. It is a system path reserved for 3rd party software such as boost.

It is a long story. DYLD LIBRARYPATH might work as long as you always run your software from the command line.

The export, not set should be used, but even then XCode fails to link properly (same error message).

That variable is not related to linking. It tells the application where to find dynamic libraries when the application runs. If you are having trouble linking your application, it is something else.

I do not know if boost will even compile properly on 10.6. It is the most complicated C++ library in existence. Plus, the GCC 4.2 compiler in 10.6 is known to have serious bugs, especially in debug mode. You MUST start by compiling boost with exclusively default options. There is no other way.