x86_64-pc-linux-gnu-gcc -o vsftpd -Wl,-O1 -Wl,--as-needed -fPIE -pie -Wl,-z,relro -Wl,-z,now main.o utility.o prelogin.o ftpcmdio.o postlogin.o privsock.o tunables.o ftpdataio.o secbuf.o ls.o postprivparent.o logging.o str.o netstr.o sysstr.o strlist.o banner.o filestr.o parseconf.o secutil.o ascii.o oneprocess.o twoprocess.o privops.o standalone.o hash.o tcpwrap.o ipaddrparse.o access.o features.o readwrite.o opts.o ssl.o sslslave.o ptracesandbox.o ftppolicy.o sysutil.o sysdeputil.o seccompsandbox.o -Wl,-O1 -Wl,--as-needed -fPIE -pie -Wl,-z,relro -Wl,-z,now `./vsf_findlibs.sh` /lib/libpam.so.0: error adding symbols: File in wrong format collect2: error: ld returned 1 exit status Makefile:29: recipe for target 'vsftpd' failed This error occurs when using an amd64 profile with SYMLINK_LIB=no and LIBDIR_x86=lib. The vsf_findlibs.sh script outputs "/lib/libpam.so.0", which is a 32-bit library.
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
