| Summary: | net-ftp/vsftpd-3.0.2-r2[pam] /lib/libpam.so.0: error adding symbols: File in wrong format | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mike Gilbert <floppym> |
| Component: | [OLD] Unspecified | Assignee: | Markos Chandras (RETIRED) <hwoarang> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugs, net-ftp, proxy-maint, wired |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 506276 | ||
| Attachments: |
Replace /lib/libpam.so.0 with -lpam
Revised patch Revised patch II Override LIBS variable |
||
|
Description
Mike Gilbert
2014-04-19 21:30:31 UTC
Created attachment 375330 [details, diff]
Replace /lib/libpam.so.0 with -lpam
This patch resolves the issue. However, this vsf_findlibs.sh script needs to die in a fire.
While you are at it, could you also add a call to epatch_user? This makes testing patches easier.
(In reply to Mike Gilbert from comment #0) > This error occurs when using an amd64 profile with SYMLINK_LIB=no and > LIBDIR_x86=lib. > Is this a supported configuration? What amd64 profile is this? (In reply to Mike Gilbert from comment #1) > Created attachment 375330 [details, diff] [details, diff] > Replace /lib/libpam.so.0 with -lpam > > This patch resolves the issue. However, this vsf_findlibs.sh script needs to > die in a fire. > Is it safe to use both /usr/lib and /usr/lib64 in there? You assume that if the first one is not a symlink, then you need to use that one, otherwise it does not matter. What about /lib32 ? Again, I am not sure what's the layout in the profile you are using. > While you are at it, could you also add a call to epatch_user? This makes > testing patches easier. Sure (In reply to Markos Chandras from comment #2) > Is this a supported configuration? What amd64 profile is this? Not really a profile yet, just my own config in make.conf. See bug 506276; base-system is starting to think about making this the default configuration. (In reply to Markos Chandras from comment #3) > Is it safe to use both /usr/lib and /usr/lib64 in there? Honestly, I'm just imitating the logic used by the rest of the script. The order of the directories is not really all that important, so long as a copy of libpam.so is located in one of them. The important part of the patch is that it outputs "-lpam" instead of an absolute path. That lets the linker do the work of finding the correct library. > Again, I am not sure what's the layout in the profile you are using. 64-bit libs in /lib64 and /usr/lib64, 32-bit libs in /lib and /usr/lib. Created attachment 375372 [details, diff]
Revised patch
The old patch looked for libpam.so.0, which is obviously wrong. Look for libpam.so instead.
Created attachment 375374 [details, diff]
Revised patch II
Actually, we can just remove the one offending line
Created attachment 375384 [details, diff] Override LIBS variable Another option to consider would be overriding the LIBS Makefile variable to avoid calling vsf_findlibs.sh at all. This is the approach that Fedora has taken. http://pkgs.fedoraproject.org/cgit/vsftpd.git/tree/vsftpd-2.1.0-libs.patch We could do something like this in the ebuild. See attached patch. I prefer avoiding running it at all. Additionally, am I the only one getting warnings about redefining fortify_source? <command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default] opts.c:1:0: note: this is the location of the previous definition Should we do something about it or does it qualify as nitpick? (In reply to Mike Gilbert from comment #7) > Created attachment 375384 [details, diff] [details, diff] > Override LIBS variable > > Another option to consider would be overriding the LIBS Makefile variable to > avoid calling vsf_findlibs.sh at all. This is the approach that Fedora has > taken. > > http://pkgs.fedoraproject.org/cgit/vsftpd.git/tree/vsftpd-2.1.0-libs.patch > > We could do something like this in the ebuild. See attached patch. Yeah I suppose a patch like this would be better. (In reply to Johan Bergström from comment #8) > I prefer avoiding running it at all. > > Additionally, am I the only one getting warnings about redefining > fortify_source? > <command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default] > opts.c:1:0: note: this is the location of the previous definition > > Should we do something about it or does it qualify as nitpick? Probably because the build systems enables _FORTIFY_SOURCE and then we have the gentoo cflags that enable it too. No reason to fix this. It's just a warning. The fedora patch seems a bit incomplete. On my system i see this output when i run the script manually _findlibs.sh -lwrap -lnsl -lnsl /lib/libpam.so.0 -lpam -lpam -ldl -lnsl -lresolv -lutil -lssl -lcrypto So i think your "Override LIBS variable" patch is what I will commit It should be fixed now in 3.0.2-r2. Thanks for the report and the patch http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-ftp/vsftpd/vsftpd-3.0.2-r2.ebuild?r1=1.1&r2=1.2 |