Re: ... linker problems

[Ralf Wildenhues]

* Antonio Coralles wrote on Mon, Jan 24, 2005 at 06:07:08PM CET:
> Ralf Wildenhues wrote:
> 
> >* Antonio Coralles wrote on Sat, Jan 22, 2005 at 12:08:32AM CET:
> >
*snip*
> >>`.gnu.linkonce.t._ZN5boost9date_time23gregorian_calendar_baseINS0_19year_month_day_baseINS_9gregorian9greg_yearENS3_10greg_monthENS3_8greg_dayEEEmE16end_of_month_dayES4_S5_'
> >> 
> >
> >>referenced in section `.rodata' of testUtils/testutils.o: defined in
> >>discarded section
> >>`.gnu.linkonce.t._ZN5boost9date_time23gregorian_calendar_baseINS0_19year_month_day_baseINS_9gregorian9greg_yearENS3_10greg_monthENS3_8greg_dayEEEmE16end_of_month_dayES4_S5_'
> >> 
> >
> [snip]
> 
> Well this problem is allready solved. I can't tell what it was exactly, 
> but I still get this error when I try to mix object or *.a files 
> compiled with different flags. The problems I'm experiencing now are 
> explained in "strange problems".

Ok, let's see:

> Ok, here is my old link command line:
> 
> g++ -Wall -g `pkg-config gtkmm-2.4 --libs` 
> ../../../objectFiles/messageMem.o -lsqlite -lboost_date_time 
> ../../../objectFiles/worker.o ../../../objectFiles/schedule.o 
*snip many objects*
> ../../../objectFiles/poolScheduleField.o ../../../objectFiles/main.o -o 
> mainTest; \

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

> 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.

> 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.
Maybe also check that you are not by chance linking against several
pthreads libraries.

Regards,
Ralf