https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: app-backup/bacula-11.0.6 installs files with unresolved SONAME dependencies. Discovered on: amd64 (internal ref: ci)
CC'ing also the author of the commit (86bdb5ca9634d10a4bcf7d24d2869508987af78d)
Created attachment 779312 [details] build.log build log and emerge --info
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8dcf61a9bbe52845be829ba9f49680d5f1932e32 commit 8dcf61a9bbe52845be829ba9f49680d5f1932e32 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-05-17 06:09:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-05-17 06:09:57 +0000 app-backup/bacula: add -r1 w/o slibtool patch Just temporarily. Bug: https://bugs.gentoo.org/790140 Bug: https://bugs.gentoo.org/845126 Signed-off-by: Sam James <sam@gentoo.org> ...acula-11.0.6.ebuild => bacula-11.0.6-r1.ebuild} | 3 - app-backup/bacula/files/bacula-fix-slibtool.patch | 128 --------------------- 2 files changed, 131 deletions(-)
I don't understand it. The QA warning is triggered, but the libraries are installed with the package and ldd(1) does find them. $ ldd /usr/sbin/bacula-dir linux-vdso.so.1 (0x00007ffc62992000) libbacfind-11.0.6.so => /usr/lib64/libbacfind-11.0.6.so (0x00007f3f17322000) libbacsql-11.0.6.so => /usr/lib64/libbacsql-11.0.6.so (0x00007f3f172e9000) libbaccats-11.0.6.so => /usr/lib64/libbaccats-11.0.6.so (0x00007f3f172e1000) libbaccfg-11.0.6.so => /usr/lib64/libbaccfg-11.0.6.so (0x00007f3f172cc000) libbac-11.0.6.so => /usr/lib64/libbac-11.0.6.so (0x00007f3f17235000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/libstdc++.so.6 (0x00007f3f1702b000) libc.so.6 => /lib64/libc.so.6 (0x00007f3f16e32000) libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007f3f16ccd000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f3f16cc0000) libz.so.1 => /lib64/libz.so.1 (0x00007f3f16ca6000) libssl.so.52 => /usr/lib64/libssl.so.52 (0x00007f3f16c35000) libcrypto.so.49 => /usr/lib64/libcrypto.so.49 (0x00007f3f16a13000) libm.so.6 => /lib64/libm.so.6 (0x00007f3f16937000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/libgcc_s.so.1 (0x00007f3f1691d000) /lib64/ld-linux-x86-64.so.2 (0x00007f3f1740b000) $ ldd /usr/lib64/libbaccats-11.0.6.so linux-vdso.so.1 (0x00007ffff11e3000) libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007f5ce65d3000) libc.so.6 => /lib64/libc.so.6 (0x00007f5ce63c4000) libm.so.6 => /lib64/libm.so.6 (0x00007f5ce62ea000) /lib64/ld-linux-x86-64.so.2 (0x00007f5ce6742000)
Seems they are doing something special that confuses the QA and I fixed to to correctly pass the -soname to the linker which exposed the issue. In src/cats/install-default-backend.in: # # Create a default catalog library pointing to one of the shared libs. # rm -f ${install_dir}/libbaccats-${library_version}${SHLIB_EXT} # # Create a relative symlink to the default backend # As all backends are in the same directory anyhow this should # always work. # ln -s libbaccats-${default_backend}${SHLIB_EXT} \ ${install_dir}/libbaccats-${library_version}${SHLIB_EXT} lrwxrwxrwx 1 root root 21 May 17 10:28 /usr/lib64/libbaccats-11.0.6.so -> libbaccats-sqlite3.so lrwxrwxrwx 1 root root 20 May 17 10:28 /usr/lib64/libbaccats.so -> libbaccats-11.0.6.so -rwxr-xr-x 1 root root 27008 May 17 10:28 /usr/lib64/libbaccats-sqlite3-11.0.6.so lrwxrwxrwx 1 root root 28 May 17 10:28 /usr/lib64/libbaccats-sqlite3.so -> libbaccats-sqlite3-11.0.6.so
(In reply to orbea from comment #5) > Seems they are doing something special that confuses the QA and I fixed to > to correctly pass the -soname to the linker which exposed the issue. > Some background for the soname problem was discussed in bug #602952 (esp. comment 8). bacula can be configured during compile to use sqlite, mysql or postgresql as database. All components access it via libbaccat.so. That gets linked to the actual database library in use (e.g. -> libbaccat-sqlite3.so). For build with libtool the problem is solved via the '-soname' switch. That mechanism may be needed for a slibtool build also.
The problem is that -soname is a linker flag, not a libtool flag. You will find that libtool will silently ignore flags it doesn't know while slibtool doesn't. The solution is to actually pass -soname to the linker with -Wl, not change ltmain.sh. However that confuses the Gentoo QA. Additionally there is something seriously in-optimal about compiling libbaccat.so, installing it, removing it and then symlinking it to another library by grepping the output of GNU libtool.
(In reply to orbea from comment #7) > The problem is that -soname is a linker flag, not a libtool flag. You will > find that libtool will silently ignore flags it doesn't know while slibtool > doesn't. > > The solution is to actually pass -soname to the linker with -Wl, not change > ltmain.sh. However that confuses the Gentoo QA. Right. Above was just ment to clarify. > Additionally there is something seriously in-optimal about compiling > libbaccat.so, installing it, removing it and then symlinking it to another > library by grepping the output of GNU libtool. I aggree. But that is something which is not in our hands. There are quite some problems in upstream's build process (flags, order of libraries and others). And upstream was always quite obstinate if we suggested changes - partly understandable as it has to work on quite a lot of different systems.
What I was trying to say is that the patch that exposed this to fix slibtool is still correct and better than what was before. Whatever -soname issues with the gentoo QA existed before my change and was obscured by how -soname apparently never made it to the linker. I'm not sure how to fix the QA, but reverting the patch that exposed the issue is just shoving the issue under the rug. Also the upstream script will probably an issue in the future if we ever fully move away from GNU libtool.
Sorry for being late. Real life requires some time.... (In reply to orbea from comment #9) > What I was trying to say is that the patch that exposed this to fix slibtool > is still correct and better than what was before. Whatever -soname issues > with the gentoo QA existed before my change and was obscured by how -soname > apparently never made it to the linker. > As far as I can see there were no issues with gentoo QA before your patch. The problem is that libbaccats.so is a link to the db library. As a link has no SONAME itself we change the SONAME of the db library instead. I agree that this is a hack, but no QA problem. > The solution is to actually pass -soname to the linker with -Wl, not change > ltmain.sh. However that confuses the Gentoo QA. I agree about the idea. The problem is - it does not work. Grepping through the emerge output shows the '-Wl,-soname,libbaccats-11.0.06.so' while building the db library. But using scanelf on the installed library shows that the SONAME got not changed. $ scanelf -S /usr/lib64/libbaccats-sqlite3.so TYPE SONAME FILE ET_DYN libbaccats-sqlite3-11.0.6.so /usr/lib64/libbaccats-sqlite3.so It seems something is still wrong with the patch. Can you please double check?
> As far as I can see there were no issues with gentoo QA before your patch. It wasn't using soname at all before since GNU libtool silently ignores unknown arguments. > I agree about the idea. The problem is - it does not work. The log attached to this issue shows: -Wl,-soname,libbaccats-11.0.6.so And as far as I can tell your scanelf output is correct.
(In reply to orbea from comment #11) > > As far as I can see there were no issues with gentoo QA before your patch. > > It wasn't using soname at all before since GNU libtool silently ignores > unknown arguments. > > > I agree about the idea. The problem is - it does not work. > > The log attached to this issue shows: > > -Wl,-soname,libbaccats-11.0.6.so > > And as far as I can tell your scanelf output is correct. In the mean time I did some further investigations. The above -Wl,... is indeed fed via libtool to the linker. But unfortunately libtool itself adds another autogenerated -Wl,-soname,libbaccats-sqlite3-11.0.6.so afterwards which overrides the first one. The patch from bacula-fix-soname.patch changes libtools behavior so that we can feed a soname from the command line and override the addition of the second -soname switch (see ltmain.sh for details). At the moment I am not able to test the details with slibtool. Do you observe the same QA warning when compiling with slibtool? An idea would be to check in the ebuild if libtool or slibtool is used and apply one of the bacula-fix-.... patches accordingly. What do you think?
As it turns out slibtool mimics the behavior of libtool with regards to forcing the soname of a library to itself. That means the original patch for enabling slibtool is not working at all. It should also be dropped from baculas mantis bug tracking system. In the moment I am testing to set the soname of the library AFTER libtool or slibtool has build it with dev-util/patchelf. Looks promising but needs some more tests.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e453613efdefbc2fbac2ed0454c3571e68276ceb commit e453613efdefbc2fbac2ed0454c3571e68276ceb Author: Thomas Beierlein <tomjbe@gentoo.org> AuthorDate: 2022-06-03 07:51:10 +0000 Commit: Thomas Beierlein <tomjbe@gentoo.org> CommitDate: 2022-06-03 07:58:06 +0000 app-backup/bacula: Fix soname in libbaccat.so i Actual libtool needs a patch to accept '-soname' command line switch, otherwise it will ignored. slibtool in contrast responds with error and is not easy to patch. Solution here drops the '-soname' switch and uses patchelf program to fix the SONAME after the library is build. Closes: https://bugs.gentoo.org/790140 Closes: https://bugs.gentoo.org/845126 Signed-off-by: Thomas Beierlein <tomjbe@gentoo.org> app-backup/bacula/bacula-11.0.6-r2.ebuild | 417 +++++++++++++++++++++ .../bacula/files/bacula-fix-sonames-new.patch | 37 ++ 2 files changed, 454 insertions(+)
