Linking problem w. wxPython (core_wrap.o)

--progress report--

solved the linking problems. It appeared that I was missing some libs in the link command, namely added "-lz -ltiff -lpng". My link command:

···

-----------------------------------
g++ -g -o b1 b1.o example.o example_wrap.o core_wrap.o libpy.o helpers.o drawlist.o `wx-config --libs` -D__WXGTK__ -DwxUSE_BASE=1 -D__WXDEBUG__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/q/wxPy/src/tiff -I/q/wxPy/src/jpeg -I/q/wxPy/src/png -I/q/wxPy/src/zlib/zlib.h -I/q/wxPy/src/expat/lib -I/q/wxPy/src/../include /usr/local/lib/python2.3/config/libpython2.3.a -lnsl -ldl -lreadline -ltermcap -lieee -lpthread -lutil -lz -ltiff -lpng -lm

core_wrap.o: In function `wxGetApp(void)':
/c/d/wx/wx/./mygtk/core_wrap.cpp(.text+0x23a8): multiple definition of `wxGetApp(void)'
b1.o(.text+0x3478):/c/d/wx/wx/b1.cpp: first defined here
/usr/local/lib/python2.3/config/libpython2.3.a(posixmodule.o): In function `posix_tmpnam':
/z/Python-2.3/./Modules/posixmodule.c:5783: the use of `tmpnam_r' is dangerous, better use `mkstemp'
/usr/local/lib/python2.3/config/libpython2.3.a(posixmodule.o): In function `posix_tempnam':
/z/Python-2.3/./Modules/posixmodule.c:5738: the use of `tempnam' is dangerous, better use `mkstemp'
collect2: ld returned 1 exit status
make: *** [b1] Error 1
-----------------------------------

Noy, the python-related messages should be only warnings, so I'll ignore those, which leaves us with the multiple defs of 'wxGetApp(void)' error. Robin Dunn suggested this is caused because I'm linking the wx libs more than once. In "b1.cpp", I guess it must conflict with the macro:

-----------------------------------
// Create a new application object: this macro will allow wxWindows to create
// the application object during program execution (it's better than using a

// static object for many reasons) and also declares the accessor function
// wxGetApp() which will return the reference of the right type (i.e. MyApp and
// not wxApp)
IMPLEMENT_APP(MyApp)
-------------------------

So I guess I'll have to comment this macro out, and find another way to create the app object.
Let's see...
Vio

Vio wrote:

core_wrap.o: In function `wxGetApp(void)':
/c/d/wx/wx/./mygtk/core_wrap.cpp(.text+0x23a8): multiple definition of `wxGetApp(void)'
b1.o(.text+0x3478):/c/d/wx/wx/b1.cpp: first defined here

I didn't see this one before.

Noy, the python-related messages should be only warnings, so I'll ignore those, which leaves us with the multiple defs of 'wxGetApp(void)' error. Robin Dunn suggested this is caused because I'm linking the wx libs more than once. In "b1.cpp", I guess it must conflict with the macro:

-----------------------------------
// Create a new application object: this macro will allow wxWindows to create
// the application object during program execution (it's better than using a

// static object for many reasons) and also declares the accessor function
// wxGetApp() which will return the reference of the right type (i.e. MyApp and
// not wxApp)
IMPLEMENT_APP(MyApp)

Yes, that is the problem. You must be the first one who has tried to link statically to wxPython modules otherwise this would have come up before. I can probably change the name of the C part of the wxGetApp function that wxPython implements so it doesn't conflict with the one created by IMPLEMENT_APP.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!