[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ... linker problems

From: Antonio Coralles
Subject: Re: ... linker problems
Date: Mon, 24 Jan 2005 23:23:44 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041223)

Antonio Coralles wrote:

Ralf Wildenhues wrote:


What does
  pkg-config gtkmm-2.4 --libs


-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/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'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

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.


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


I get eaven more stranger errors when I try to do something in my prog, without loading a file:

[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 20862)]
free(): invalid pointer 0x8507180!

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 20862)]
0x409d2bbf in mallopt () from /lib/
(gdb) back
#0  0x409d2bbf in mallopt () from /lib/
#1  0x409d29e4 in mallopt () from /lib/
#2  0x409d16bd in free () from /lib/
#3  0x407c1ae3 in g_free () from /usr/lib/
#4  0x08508ca8 in ?? ()
#5  0x085077e8 in ?? ()
#6  0x4078ea3c in ?? () from /usr/lib/
#7  0x40765732 in g_object_new_valist () from /usr/lib/
#8  0x402a9b4c in ?? () from /usr/lib/

Once I had similar problems [completly independent from automake]. I finally solved them by moving from -lboost_date_time to -lboost_date_time-gcc [that was with another release of boost - this file now doesn't exist any more] - so I'm sure that the error is hidden somewhere in the linker options - but I really have no clue where ..


reply via email to

[Prev in Thread] Current Thread [Next in Thread]