embedding python, missing symbols

[Jack Diederich]

I can't seem to make gcc happy

using the example main() from the embedding docs and doing

gcc -I<path to Python.h> ./libpython2.2.a example.c

gives the following error

/tmp/ccBiGJVU.o: In function `main':
/tmp/ccBiGJVU.o(.text+0x2d): undefined reference to `Py_Initialize'
/tmp/ccBiGJVU.o(.text+0x3d): undefined reference to `PyString_FromString'
/tmp/ccBiGJVU.o(.text+0x50): undefined reference to `PyImport_Import'
<snip, more of the same>
/tmp/ccBiGJVU.o(.text+0x299): undefined reference to `Py_Finalize'

./libpython2.2.a is a hard link to the one installed in /usr/local

I tried with python2.2 and 2.3a1
I tried with gcc 2.96 and 3.0.4

redhat 7.1 with recompiled pythons and gccs

grepping the libpython* binaries shows a match for all the symbols

similar errors on groups.google are because the libpython*.a wasn't
included. I am including the lib ... gcc just doesn't care.

I must be missing something obvious, please let me know what it is!

btw, mod_python and other things compile happilly on the same machine.

TIA,

-jackdied

[Two Inches]

Jack Diederich wrote:
> I can't seem to make gcc happy
>
> using the example main() from the embedding docs and doing
>
> gcc -I<path to Python.h> ./libpython2.2.a example.c

Use -L to tell gcc where to search for libs and -l to tell it which libs
to link against.

something like this should work (not tested; I do prefer to separate
compiling and links as a matter of taste):

gcc -o example.o -I<path to Python.h> example.c
gcc example.o -o example -L<path to Python-libs> -lpython2.2

You may also want to read some decent (g)cc documentation.

[Jack Diederich]

On Sat, Jan 25, 2003 at 12:08:41PM +0100, Two Inches wrote:
> Jack Diederich wrote:
> > I can't seem to make gcc happy
> >
> > using the example main() from the embedding docs and doing
> >
> > gcc -I<path to Python.h> ./libpython2.2.a example.c
>
> Use -L to tell gcc where to search for libs and -l to tell it which libs
> to link against.
>
> something like this should work (not tested; I do prefer to separate
> compiling and links as a matter of taste):
>
> gcc -o example.o -I<path to Python.h> example.c
> gcc example.o -o example -L<path to Python-libs> -lpython2.2
>

The -L<path> -l<name> combination gets translated to the plainer
full-path of the actual .a lib. It's a lot more flexible for distributing
makefiles, but equivalent to the above.

I get the same errors
/tmp/cce2iMj2.o(.text+0x31): undefined reference to `Py_Initialize'
/tmp/cce2iMj2.o(.text+0x41): undefined reference to `PyString_FromString'
/tmp/cce2iMj2.o(.text+0x52): undefined reference to `PyImport_Import'
<snip>
/tmp/cce2iMj2.o(.text+0x295): undefined reference to `Py_Finalize'

-jackdied

[Martin v. Löwis]

Jack Diederich <ja...@performancedrivers.com> writes:

> > > gcc -I<path to Python.h> ./libpython2.2.a example.c

> > gcc -o example.o -I<path to Python.h> example.c
> > gcc example.o -o example -L<path to Python-libs> -lpython2.2
> The -L<path> -l<name> combination gets translated to the plainer
> full-path of the actual .a lib. It's a lot more flexible for distributing
> makefiles, but equivalent to the above.

No, it's not. You are passing libpython2.2.a first; this is
incorrect. In the second invocation, -lpython2.2 is passed last.

> I get the same errors
> /tmp/cce2iMj2.o(.text+0x31): undefined reference to `Py_Initialize'
> /tmp/cce2iMj2.o(.text+0x41): undefined reference to `PyString_FromString'
> /tmp/cce2iMj2.o(.text+0x52): undefined reference to `PyImport_Import'
> <snip>
> /tmp/cce2iMj2.o(.text+0x295): undefined reference to `Py_Finalize'

I can't really believe that. Are you sure you are invoking the
compiler precisely as suggested?

Regards,
Martin

[Jack Diederich]

On Sat, Jan 25, 2003 at 10:10:54PM +0100, Martin v. Löwis wrote:
> Jack Diederich <ja...@performancedrivers.com> writes:
>
> > > > gcc -I<path to Python.h> ./libpython2.2.a example.c
> > > gcc -o example.o -I<path to Python.h> example.c
> > > gcc example.o -o example -L<path to Python-libs> -lpython2.2
> > The -L<path> -l<name> combination gets translated to the plainer
> > full-path of the actual .a lib. It's a lot more flexible for distributing
> > makefiles, but equivalent to the above.
>
> No, it's not. You are passing libpython2.2.a first; this is
> incorrect. In the second invocation, -lpython2.2 is passed last.

Ahh, I didn't know order was ever important. For Makefiles libs go at the
end out of habit, typing it by hand introduced the error.

Thank you, it now works as expected.

-jackdied