[C++-sig] Link trouble on OS X

[David Abrahams]

----- Original Message -----
From: "Scott A. Smith" <ssmith at magnet.fsu.edu>
To: <c++-sig at python.org>
Sent: Thursday, May 30, 2002 10:07 AM
Subject: RE: [C++-sig] Link trouble on OS X


> Hi again,
>
> > Hmm, if it's looking for _main, it seems as though it thinks you're
trying
> > to build an executable. Are you using Boost.Build or are you trying to
do
> > something else?
>
> I am just running bjam in the libs/python/build subdirectory, is that
using
> Boost.Build?

Yes.

> What is Boost.Build, just the hierarchy of Jam files for Boost?

It's more the contents of the tools/build directory.

> > Also, are you building your own extension at this point, or just trying
to
> > build bpl.so?
>
> Just trying to build the Boost.Python library. This was
> boost_python.(dll/lib)
> on my PC with both Cygwin & MSVC++. Is this called bpl.so on Unix
systems?

Yes.

> If so, then yes that is what I am trying to make.
>
> Here is a recap:

<snip>

> Here is the full command and output, yuk.
>
> =================================================================
>
> export LD_LIBRARY_PATH
> c++   -s -fPIC -shared  -o
>
"../../../libs/python/build/bin/libboost_python.so/gcc/release/inlining-on/
r
>
ntime-link-dynamic/shared-linkable-true/libboost_python.so"  -L/sw/lib/pyth
> on2.2/config

<snip>

> untime-link-dynamic/shared-linkable-true/errors.o" -lpython2.2
>
> /usr/bin/ld: Undefined symbols:
> _main
  ...

Thanks, this stuff helps.

> =================================================================
>
> Note that the bjam command directly will also produce the problem
> with _main (so it's less likely I goofed in copying the c++ command
line).
> Could this be a problem in the compilation/link flags set?

Yes, it could be. What does it take to build a shared library on OS X?
Normally, -fPIC -shared is enough to do it on a Linux/ELF system, but GCC
running on OS X may have different requirements.

> I read that
> they want users to insure that no pre-compiled headers are used

That's a non-issue in our case.

> and that
> there is some special treatment of shared libraries

If you can find out what that is, it would help, since that's what you're
trying to build.

> , but since I don't
> full comprehend the Boost.build process I am a bit leery to experiment.
> Should I try messing with python.jam and/or gcc-tools.jam?

I don't think that's a good idea. You have the entire text of the build
commands we're currently using. Why don't you stick those in a shell script
and twiddle the flags until you get it to work? If you can tell us what the
command-lines should look like, we can modify the appropriate parts of
Boost.Build to make it work.

> Perhaps there
> is just some problem is setting the appropriate directories to look,
> although setting  GCC_ROOT_DIRECTORY expliclty didn't do any good.

It doesn't look like  a search path problem to me at this point.

-Dave