Re: [boost] Linking Boost.Python

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-29 00:49:26

----- Original Message -----
From: "Nokome Bentley" <nbentley_at_[hidden]>

> Hi,
>
> Thanks Dave for your prompt reply to my question. I hope that the
> descriptions of my continued problems are useful and not just clutter on
the
> list. I followed your instructions and JAM ran but I had to change some
> things:
>
> 1. I changed the g++ to gxx in "actions gcc-C++-action" in
> tools/build/gcc-tools.jam

On what platform is gcc c++ spelled "gxx"?

> 2. Then I learnt about the apparently "infamous DOS 126-character limit"
> for commands. To get around that I wrote a program (DOSWrite) to write a
> command text file that could be read in by gcc:

What OS are you using? The limit on NT is 2047 characters.

> #include <fstream.h>
> int main(int argc, char* argv[]){
> ofstream file(argv[1]);
> for(int i=2;i<=argc;i++) file<<argv[i]<<" ";
> return 0;
> }
>
> and in tools/build/gcc-tools.jam changed actions gcc-C++-action to
>
> actions gcc-C++-action
> {
> DOSWrite
> base.txt -c -Wall -ftemplate-depth-100 -U$(UNDEFS) -D$(DEFINES)$(CFLAGS)
> $(C++FLAGS)
> DOSWrite files.txt " " -I"$(HDRS)" -I"$(STDHDRS)" -o "$(<)" "$(>)"
> COPY /Y base.txt+files.txt coms.txt
> $(GCC_BIN_DIRECTORY)gxx @coms.txt
> }

You don't need a separate file for this (see msvc-tools.jam in CVS for
example), but:
1. My version of gcc (for cygwin) doesn't support command files (@file) --
you have me very confused! Are you sure you're using gcc?

2. There's a better way around this under Boost.Jam for commands which can
be executed all in a single line: just set

JAMSHELL on $(<) = % ;

where $(<) is the target you're building. That should be integrated into
Boost.Build for gcc.

> 3. I changed the PYTHON_INCLUDES variable in libs/python/build Jamfile so
> that it included the directory where I have Python

If you're running under Windows, it should be sufficient to set PYTHON_ROOT
and if neccessary, PYTHON_VERSION, either in your environment or on the Jam
command-line. If that works, it's probably the better approach.

> This seems to work but when it gets to:
>
>
>
gxx -c -Wall -ftemplate-depth-100 -DSIZEOF_LONG=4 -DUSE_DL_IMPORT -g -O0 -
> fno-inline -fPIC
> -I"libs\python\build" -I"." -I"c:\progra~1\python21\include"
> -o
>
"libs\python\build\bin\libboost_python\gcc\debug\runtime-link-dynamic\shared
> -linkable-true\classes.obj"
> "libs\python\build\../src\classes.cpp"
>
> then I get:
>
> c:/program files/djgpp/bin/as.exe: bfd assertion fail
> /djgpp/gnu/binutl-2.112/bfd/coff-i386.c:529
> c:/program files/djgpp/tmp\ccxmWUEa.s: Assembler messages:
> c:/program files/djgpp/tmp\ccxmWUEa.s:1649: Error: cannot represent
> relocation type BFD_RELOC_386_PLT32
> c:/program files/djgpp/bin/as.exe: bfd assertion fail
> /djgpp/gnu/binutl-2.112/bfd/coff-i386.c:529
> c:/program files/djgpp/tmp\ccxmWUEa.s:1653: Error: cannot represent
> relocation type BFD_RELOC_386_GOTOFF
>
> Removing the option -fPIC allows compilation. I experimented without this
> option and built libboost_python.lib using the 9 .obj files:

If you get the latest version of the build system from CVS, you'll find
that -fPic doesn't occur under windows anymore.

> ar ru libboost_python.lib classes.obj.....
>
> But when I go to use it get:
>
> gxx -shared -o gs2.pyd
>
getting_started2.o -Llibboost_python.lib -Lc:\progra~1\python21\libs\python2
1.lib
----------------------^---------------------^
Do those Ls really come out capitalized? If you are really using gcc, then
they should not be. -L is used to specify library search paths, not actual
libraries.

> gcc.exe: unrecognized option `-shared'

If your gcc doesn't support shared linking, you won't be able to build a
python module; I don't know what to tell you...

> c:/program files/djgpp/lib/crt0.o(.data+0xc2):crt0.s: undefined reference
to
> `main'
> getting_started2.o(.text+0xd4):getting_started2.cpp: undefined reference
to
> `boost::python::module_builder::module_builder(char const*)'
> getting_started2.o(.text+0x19f):getting_started2.cpp: undefined reference
to
...

> so I suppose that the -fPIC really is needed.

I don't think that's the right conclusion. The symbols you're seeing are
defined in libboost_python.lib. It's not being properly linked into your
shared library.

-Dave