+++ This bug was initially created as a clone of Bug #146132 +++ 0.99.9.0 still tries to build and then run padout. Here is a trivial ebuild workaround. This isn't perfect because the two source files still include the config.h for the target system, but this works for me and since cross-compile is 100% broken without this it seems like an improvement. diff -r 1b67b1831be6 sys-libs/pam/pam-0.99.9.0.ebuild --- a/sys-libs/pam/pam-0.99.9.0.ebuild Tue Jan 15 17:57:12 2008 -0500 +++ b/sys-libs/pam/pam-0.99.9.0.ebuild Wed Jan 16 15:42:24 2008 -0500 @@ -133,6 +133,12 @@ src_compile() { --enable-docdir=/usr/share/doc/${PF} \ --disable-regenerate-man \ ${myconf} || die "econf failed" + + if tc-is-cross-compiler; then + echo "Building native padout build tool" + make -C doc/specs CC=gcc padout || die "Native padout build failed" + fi + emake || die "emake failed" }
Hmm... you try build pam-0.99.9 with uclibc? It's need this patch http://www.uclibc.org/bugs/view.php?id=1789 ?
That uclibc patch is way bigger than it needs to be. Almost all of what it is trying to do can be accomplished by setting: ac_cv_lib_nsl_yp_get_default_domain=no ac_cv_func_yp_get_default_domain=no in the environment when the configure command is run. I will attach a smaller version (258 lines vs. 1186 lines) of the patch that just disables NIS. This should only be applied in the uclibc case though (and only assuming that our uclibc doesn't support NIS).
Created attachment 141146 [details, diff] Smaller patch to disable NIS in uclibc case
Please don't submit patches that upstream will not accept please don patch Makefile.in either. Unfortunately my ppc cross-compiler does not seem to like to work, once I fix that I'll try to prepare a patch for autotools that hopefully will fix once and for all, but I want all the patches to be upstreamable.
Yeah, I don't like the uclibc patch either, I was just simplifying it by removing the majority of it that was obviously not needed. For the padout issue do you want me to come up with a upstreamable patch? Basically what should happen there is that CC_FOR_BUILD should be used to generate padout, not CC.
What I can check for now is if CC_FOR_BUILD is automatically generated by autoconf. Once that's fine, it should be enought to set padout_CC = $(CC_FOR_BUILD) (in theory CFLAGS should also be ignored then).
Created attachment 172393 [details, diff] Fixes crosscompilation issues We don't like make -C in ebuilds. This patch fixes compilation issues. We need not only change the compiler, but also unset CFLAGS and LDFLAGS to aviod errors like: gcc -DHAVE_CONFIG_H -I. -I../.. -Os -pipe -march=armv4t -mtune=arm920t -fomit-frame-pointer -I/usr/armv4tl-softfloat-linux-gnueabi/usr/include/ -I/usr/armv4tl-softfloat-linux-gnueabi/include/ -D_GNU_SOURCE -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Wwrite-strings -Winline -Wshadow -c parse_l.c parse_l.c:1: error: bad value (armv4t) for -march= switch parse_l.c:1: error: bad value (arm920t) for -mtune= switch make[4]: *** [parse_l.o] Error 1 Tested with crossdev and crossdev-wrappers
Patch refused.
(In reply to comment #8) > Patch refused. > Care to explain? If something is wrong with it, I can fix it I guess.
It's totally unconditional in the makefile, it's certainly _not_ the way this should be implemented. I'd sincerely prefer if somebody were to talk with the upstream devs about these issues.
(In reply to comment #10) > It's totally unconditional in the makefile, it's certainly _not_ the way this > should be implemented. So where should be better place to implement it? I'm pretty sure ebuild isn't the right place either. > I'd sincerely prefer if somebody were to talk with the upstream devs about > these issues. > Well it's been 10 months since this bug was posted and no one has done it yet. No problem I can do it.
Created attachment 183111 [details, diff] Allows PAM to cross-compile via ebuild patch. Since it appears that there's still unresolved debate on how to fix this, I like the original patch of modifying the ebuild directly. This avoids having to patch configure and MAkefile scripts directly or anything else messy. There's a bug open upstream, but no comment on the bug, and I would not hold my breath on a comment being received for quote some time. The attached patch avoids make -C, and uses toolchain-funcs to fetch the BUILD_CC, as well as setting CFLAGS/LDFLAGS to nothing. The utility only gets built this way if it's a cross-compiler anyways, and so this should be almost no impact to the average user. Thoughts? Tested on x86_64-pc-linux-gnu --> mipsel-unknown-linux-gnu build. I don't think we'll get any cleaner without hacking the source directly at this rate.
Created attachment 183113 [details, diff] Allows PAM to cross-compile via ebuild patch. Probably inconsequential (and the build still worked fine without it), but I forgot to change back to "${S}" after building the padout separately if tc-is-cross-compiler.
Ah, forgot to drop the "echo "Building native padout build tool"" bit, too. The build shoots by my screen so fast that it seems pointless to have it.
(In reply to comment #10) > It's totally unconditional in the makefile, it's certainly _not_ the way > this should be implemented. Wrong! If you look closely at the patch, you see that already the configure.in part handles the cross-compile condition.
Fixed by downloading and merging the documentation as provided by upstream in 1.1.0.
Please reopen the bug, as building pam-1.1.0 also fails with: /bin/sh ../../libtool --tag=CC --mode=link armv4tl-softfloat-linux-gnueabi-gcc -O2 -pipe -march=armv4t -mtune=arm920t -fomit-frame-pointer -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Wwrite-strings -Winline -Wshadow -Wl,--as-needed -Wl,-O1 -o padout parse_l.o parse_y.o -lfl libtool: link: armv4tl-softfloat-linux-gnueabi-gcc -O2 -pipe -march=armv4t -mtune=arm920t -fomit-frame-pointer -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Wwrite-strings -Winline -Wshadow -Wl,-O1 -o padout parse_l.o parse_y.o -Wl,--as-needed -lfl ./padout < ./draft-morgan-pam.raw > draft-morgan-pam-current.txt /bin/sh: ./padout: cannot execute binary file make[4]: *** [draft-morgan-pam-current.txt] Error 126 You really should apply Linux-PAM-1.0.2-cross-compile.patch as this is a valid and correct fix!
Not going to patch PAM for cross compile myself, YOU'VE GOT TO PUSH IT UPSTREAM. And I get _quite_ sick of this now.
