Summary: | app-backup/bacula-5.2.5 on HPPA - Compiling ing_test.c /// work/bacula-5.2.5/src/cats/.libs/libbaccats.so: undefined reference to `Jmsg(JCR*, int, long long, char const*, ...)' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | app-backup, hppa, tomjbe |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | HPPA | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 372079 | ||
Attachments: | app-backup:bacula-5.2.5:20120321-193532.log.gz [MAKEOPTS=-j1] |
Description
Jeroen Roovers (RETIRED)
2012-03-21 20:49:28 UTC
Sorry, I can not reproduce the bug here. Missed symbol comes from libbac which is included in command line. Also the directory where the library got build is correct (-L../lib). Linkage order is a little bit tricky on bacula, but never got a problem during that build stage. Have you tested it without DISTCC? (In reply to comment #1) > Sorry, I can not reproduce the bug here. > > Missed symbol comes from libbac which is included in command line. Also the > directory where the library got build is correct (-L../lib). > Linkage order is a little bit tricky on bacula, but never got a problem > during that build stage. Yes, I've looked at the command in question, and it alls seems quite right. > Have you tested it without DISTCC? If that were the cause, this would imply a bug in distcc. I'll check with another version of binutils (currently running unstable) and then check without distcc if nothing turns up there. (In reply to comment #2) > > Have you tested it without DISTCC? > > If that were the cause, this would imply a bug in distcc. I'll check with > another version of binutils (currently running unstable) and then check > without distcc if nothing turns up there. No, neither worked around the issue. (In reply to comment #3) > (In reply to comment #2) > > > Have you tested it without DISTCC? > > > > If that were the cause, this would imply a bug in distcc. I'll check with > > another version of binutils (currently running unstable) and then check > > without distcc if nothing turns up there. > > No, neither worked around the issue. I see two possible reasons: 1. Jmsg is not directly used in ing_test.c so it is brought in by some other functions which requires Jmsg in turn. That maybe a problem of linkage order (but as libbac gets linked last, it should not be a problem). We have to find which function that is. 2. Maybe a function Jmsg is found, but with a different protoype. I would suggest the following experiments to look a little bit deeper: 1. Have a look into libbac's symbol table to check if the function is exported and has the correct prototype (can be found in src/lib/.libs) 2. compile without --as-needed (just for check) 3. Test older version to see if they show the same error or not. A later diff may allow us to find the critical point. could you test 5.2.11? is the next stable target Please consider this patch to at least make clear what is happening: --- bacula-5.2.11.ebuild 12 Sep 2012 06:47:40 -0000 1.1 +++ bacula-5.2.11.ebuild 14 Sep 2012 14:45:43 -0000 @@ -124,6 +124,8 @@ epatch "${FILESDIR}"/5.2.3/${PN}-5.2.3-openssl-1.patch epatch "${FILESDIR}"/5.2.10/${PN}-5.2.10-fix-static.patch + + sed -i autoconf/Make.common.in -e '/^NO_ECHO/s:@::g' } src_configure() { I think this goes well with recent "policy" decisions, too. I see more than one problem here. First of all, configure supports --enable-acl, which we don't use. Secondly, there is a test (configure.in:2667-2674) which adds -L/usr/[libdir] to FDLIBS if and when that directory is present (and if acl is found and working). So then we get: /home/jer/portage/app-backup/bacula-5.2.11/work/bacula-5.2.11/libtool --silent --tag=CXX --mode=link /usr/bin/x86_64-pc-linux-gnu-g+ + -D_BDB_PRIV_INTERFACE_ -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -o libbaccats-sqlite3.la sqlite.lo -export-dynamic -rpath /us r/lib64 -release 5.2.11 \ -soname libbaccats-5.2.11.so -R /usr/lib64 -L/usr/lib64 -lsqlite3 which links libbaccats.so against anything plausible that is found there. This is also done in: /mnt/alt/portage/app-backup/bacula-5.2.11/work/bacula-5.2.11/libtool --silent --tag=CXX --mode=link /usr/lib/distcc/bin/hppa2.0-unknown-linux-gnu-g++ -L../lib -L../cats -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/lib -o bconsole console.o console_conf.o authenticate.o \ -lreadline -lhistory -lncurses -lbaccfg -lbac -lm -lz \ -lssl -lcrypto -lpthread -ldl -ldl And the problem is that libtool doesn't really deal with this properly. -L/usr/[libdir] means that any libbaccats is used, so my guess is that with an older bacula installed, that one gets linked against and then further linkage fails because the symbol table has changed. (In reply to comment #7) > And the problem is that libtool doesn't really deal with this properly. > -L/usr/[libdir] means that any libbaccats is used, so my guess is that with > an older bacula installed, that one gets linked against and then further > linkage fails because the symbol table has changed. Unmerging prior to the upgrade doesn't fix it, though. (In reply to comment #7) > I see more than one problem here. First of all, configure supports > --enable-acl, which we don't use. > The --enable-acl problem should be gone for hppa in bacula-5.2.12. I overlooked the autodep before. Now it is explicit via an USE=acl which is masked already for hppa. HPPA keywording removed. |