strange linkage problem with boost_date_time 1.52 (x86_64-linux-gnu/gcc version 4.7.2)
Hi erveryone, i have a little problem linking against my newly installed: boost_date_time library. I even don't know if this is the right place for this question because everything works fine so far in the past. 1. I never had problems compiling and linking this sources before (on 3 other systems). 2. The project also contains some other directories with some kind of commandline tools. These tools also link against the regex and date_time libraries without any problems. Here is the part where the libs are defined in my Makefile.am libmodwscmi_la_CXXFLAGS = $(INCLUDES) $(PROJECT_INCLUDES) $(APR_CFLAGS) libmodwscmi_la_LDFLAGS = $(LDADD) $(BOOST_LDFLAGS) $(LIB_BOOST_REGEX) $(LIB_BOOST_DATETIME) `$(APR1CONFIG) --link-ld --libs` libmodwscmi_la_LIBADD = $(top_builddir)/utils/mysqlpp/libmysqlpp.la $(top_builddir)/utils/jwsmtp/libjwsmtp.la After compiling is complete the linker gets called by this command: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.7/crtbeginS.o .libs/libmodwscmi_la-mod_wscmi.o .libs/libmodwscmi_la-mod_gsoap.o .libs/libmodwscmi_la-mod_utils.o .libs/libmodwscmi_la-mod_mysql.o .libs/libmodwscmi_la-md5.o .libs/libmodwscmi_la-regEx.o .libs/libmodwscmi_la-utils.o .libs/libmodwscmi_la-exception.o .libs/libmodwscmi_la-dateTime.o .libs/libmodwscmi_la-validator.o .libs/libmodwscmi_la-mysqlPool.o .libs/libmodwscmi_la-mysqlCons.o .libs/libmodwscmi_la-mysqlQueries.o .libs/libmodwscmi_la-sqlite3.o -Wl,-rpath -Wl,/var/www/projects/mod_wscmi-1.0/utils/mysqlpp/.libs -Wl,-rpath -Wl,/var/www/projects/mod_wscmi-1.0/utils/jwsmtp/.libs -L/usr/local/lib -lboost_date_time -lboost_regex -L/usr/lib /usr/lib/libapr-1.so -L/usr/local/mysql/lib ../utils/mysqlpp/.libs/libmysqlpp.so ../utils/jwsmtp/.libs/libjwsmtp.so -L/usr/lib/gcc/x86_64-linux-gnu/4.7 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crtn.o -pthread -O3 -Wl,-R/usr/local/lib -pthread -Wl,-soname -Wl,libmodwscmi.so.0 -o .libs/libmodwscmi.so.0.0.0 As you can see above, both libraries are present: -lboost_date_time -lboost_regex. They also can be found on the harddrive (in /use/local/lib): ... -rw-r--r-- 1 root 136876 Nov 20 09:19 libboost_date_time.a lrwxrwxrwx 1 root 28 Nov 20 09:18 libboost_date_time.so -> libboost_date_time.so.1.52.0 -rwxr-xr-x 1 root 94337 Nov 20 09:18 libboost_date_time.so.1.52.0 ... -rw-r--r-- 1 root 2619610 Nov 20 09:19 libboost_regex.a lrwxrwxrwx 1 root 24 Nov 20 09:18 libboost_regex.so -> libboost_regex.so.1.52.0 -rwxr-xr-x 1 root 1251576 Nov 20 09:18 libboost_regex.so.1.52.0 ... The complete build runs fine! There are no errors or warnings but the fianlly library is unusable because: boost_date_time is not present. Ldd shows up something like this: ldd .libs/libmodwscmi.so.0.0.0 linux-vdso.so.1 => (0x00007fff17da4000) libboost_regex.so.1.52.0 => /usr/local/lib/libboost_regex.so.1.52.0 (0x00007ff289006000) libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007ff288db5000) libmysqlpp.so.0 => /var/www/projects/mod_wscmi-1.0/utils/mysqlpp/.libs/libmysqlpp.so.0 (0x00007ff288b35000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff288832000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff288472000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff28825c000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff28803f000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007ff287e39000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff287c35000) libmysqlclient.so.18 => /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 (0x00007ff2876f1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff2873f4000) /lib64/ld-linux-x86-64.so.2 (0x00007ff2895e9000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff2871dd000) Only libboost_regex.so.1.52.0 was linked in and i have absolutly no idea why: libboost_date_time does not show up. So maybe someone of the list can give me an adivse of what's is going on here. Thanks and greetings Michael --- E-Mail ist da wo du bist! Jetzt mit freenetMail ganz bequem auch unterwegs E-Mails verschicken. Am besten gleich informieren unter http://mail.freenet.de/mobile-email/index.html
On Wed, Nov 28, 2012 at 5:50 AM,
**
Hi erveryone,
i have a little problem linking against my newly installed: boost_date_time library. I even don't know if this is the right place for this question because everything works fine so far in the past.
....
So maybe someone of the list can give me an adivse of what's is going on here.
Thanks and greetings Michael
Most of boost date-time code will be inlined, so it's entirely possible you don't need the library at all -- otherwise I can't see anything that looks wrong in your setup.
Hi Jeff, On Wed, 2012-11-28 at 16:42 -0700, Jeff Garland wrote:
Most of boost date-time code will be inlined, so it's entirely possible you don't need the library at all -- otherwise I can't see anything that looks wrong in your setup.
thanks for answering my question. The application uses some functions from the date_time library. Whenever it's started i got the following error: undefined symbol: _ZNK5boost9gregorian10greg_month15as_short_stringEv I belive there is nothing wrong with libboost_date_time and it must be a strange linkage problem on my system which i have never seen before. Greetings Michael
On Thu, Nov 29, 2012 at 3:25 AM, michaelr
thanks for answering my question. The application uses some functions from the date_time library. Whenever it's started i got the following error: undefined symbol: _ZNK5boost9gregorian10greg_month15as_short_stringEv
I belive there is nothing wrong with libboost_date_time and it must be a strange linkage problem on my system which i have never seen before.
Ok -- well indeed weird. So, if you switch stream based i/o you'll avoid the need for the library and work around your issue. Jeff
participants (3)
-
Jeff Garland
-
michaelr
-
mypop@freenet.de