Re: ... linker problems

[Antonio Coralles <noche dot suapie at reflex dot at>]

Ralf Wildenhues wrote:

[snip]

> What does
>   pkg-config gtkmm-2.4 --libs
> output?

[snip]

-Wl,--export-dynamic -lgtkmm-2.4 -lgdkmm-2.4 -latkmm-1.6 -lgtk-x11-2.0 
-lpangomm-1.4 -lglibmm-2.4 -lsigc-2.0 -lgdk-x11-2.0 -latk-1.0 
-lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 
-lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0

> > And here the new one:
> > g++  -g -Wall   -o dpm  dpm-main.o interface/mainWindow/lib_mainwindow.a
> > interface/listView/lib_listview.a
> > interface/attributeWindow/lib_attributewindow.a
> > interface/shiftTable/lib_shifttable.a interface/misc/lib_misc.a
> > htmlExport/lib_htmlexport.a messageMem/lib_messagemem.a
> > dataStorage/lib_datastorage.a utility/lib_utils.a
> > organizer/lib_organizer.a manpower/lib_manpower.a
> > labourLaw/lib_labourlaw.a schedule/lib_schedule.a
> > helperFunctions/lib_helperfunctions.a shared/lib_shared.a  
> > -Wl,--export-dynamic -lgtkmm-2.4 -lgdkmm-2.4 -latkmm-1.6 -lgtk-x11-2.0
> > -lpangomm-1.4 -lglibmm-2.4 -lsigc-2.0 -lgdk-x11-2.0 -latk-1.0
> > -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0
> > -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -L/usr/lib
> > -lboost_date_time-mt-d -lsqlite
> >
> > As one may notice: I switched from -lboost_date_time to
> > -lboost_date_time_mt-d, but it didn't work without the "_mt-d" either.
>
> I don't know boost very well, but that sounds like you are mixing
> thread-safe and non-thread-safe code.

Yes, as far as I know _mt means multithreading.  I just tried the _mt 
version because as gtk and thus gtkmm uses threads - I used the non-mt 
version before.

> > I've also partly reorganized my code, but only after experiencing
> > problems, because I thought that may help. The various *.a files are
> > created like this:
> *snip stuff I think is not important for your problem*
>
> * Antonio Coralles wrote on Mon, Jan 24, 2005 at 02:47:35AM CET:
> > I'm writing on a program [C++] for about six month. Recently I tried to
> > switch from my hand coded makefiles to autoconf/automake.  I removed all
> > my makefiles, replaced them with the according Makefile.am's and managed
> > to build my program with ./configure; make after two days. So far, so
> > good. Now the problem is, that the resulting executable contains lot's
> > of bugs - bugs which didn't occur with my hand crafted make files. I
> > tried to track them down for the last two days, without succes. To make
> > that clear: I've made no modifications to my source code - I only
> > changed the way my code gets compiled and linked.
> >
> > Additionally, I've written tests for all nontrivial core-components of
> > my programm. This tests work without problems - even when compiled with
> > with the GNU-autotools. In particular I've a test for the internals
> > responsible for loading/saving - and this test works. But when I try to
> > load a file from the main program [this works well when built with my
> > hand written makefiles] i get a strange segfault [gdb output]:
>
> Check whether all code you link against is
>   either completely thread-safe
> or
>   non-threaded.

Well, I've never written a mulithreaded application and as far as I'm 
concerned [appart from the libs I'm using] my app is single threaded.

> Maybe also check that you are not by chance linking against several
> pthreads libraries.
>
> Regards,
> Ralf

By the way, is it possible that this strange behavour is caused by 
variable names starting with _ ?

Thanks,
antonio