The good news is, with gtk fixed (see bug #133819) , little else is required and imlib doesn't any need patching, except for configure and imlib-config, so the ldflags come before the objects, and not in the output, respectively.
Created attachment 87082 [details, diff] imlib-1.9.15 --as-needed fix
Created attachment 87083 [details, diff] /imlib-1.9.15.ebuild.patch --as-needed
See the notes on bug #133820 about configure. About imlib-config.in, as that's afterward installed, you should not hardcode LDFLAGS there (if you want to know why, look at http://farragut.flameeyes.is-a-geek.org/articles/2006/05/19/why-it-is-a-bad-idea-to-record-user-settings-during-compile .
(In reply to comment #3) > See the notes on bug #133820 about configure. About imlib-config.in, as that's > afterward installed, you should not hardcode LDFLAGS there (if you want to know > why, look at > http://farragut.flameeyes.is-a-geek.org/articles/2006/05/19/why-it-is-a-bad-idea-to-record-user-settings-during-compile > . > Yeah, I know. That's the thing: upstream was hardcoding the ldflags into imlib-config, which was killing other ebuilds.
Created attachment 87223 [details, diff] imlib-1.9.15 --as-needed fix, revised Removed modifications to configure in original patch. No other way make those changes without editing libtool, configure, or aclocal.m4. Unfortunately, the order of the compiler options is set with an internal libtool macro. Still, the removal of hard coded LDFLAGS in imlib-config output is necessary to avoid trouble with other packages.
Created attachment 87226 [details, diff] imlib-1.9.15.ebuild.patch --as-needed, revised Now uses eautoreconf instead of bare calls to autoconf and automake as the one in portage now does.
Created attachment 94970 [details] emerge ' media-libs/imlib-1.9.15 ' failed hallo, both versions of ' imlib ' failed, same error :-( and this patching file /var/tmp/portage/imlib-1.9.15/work/imlib-1.9.15/ltmain.sh Hunk #1 FAILED at 3462. 1 out of 1 hunk FAILED -- saving rejects to file /var/tmp/portage/imlib-1.9.15/work/imlib-1.9.15/ltmain.sh.rej some Packages depending on imlib ! Thanks CooSee ' Ya
(In reply to comment #7) > Created an attachment (id=94970) [edit] > emerge ' media-libs/imlib-1.9.15 ' failed > > hallo, > > both versions of ' imlib ' failed, same error :-( > > and this > > patching file /var/tmp/portage/imlib-1.9.15/work/imlib-1.9.15/ltmain.sh > Hunk #1 FAILED at 3462. > 1 out of 1 hunk FAILED -- saving rejects to file > /var/tmp/portage/imlib-1.9.15/work/imlib-1.9.15/ltmain.sh.rej That doesn't make sense. None of the patches do anything to ltmain.sh; it looks like something is up with libtool on your system and possibly the eautoreconf,elibtoolize,etc. stuff is failing because of it. As to the other problem, with the undefined symbols, again, I'm not changing anything in the utils subdirectory. I do notice from the compiler output that you were (and possibly still are) using a binutils patched for -Bdirect and that your ldflags are a bit, umm, shall we say "comprehensive". E.g.: -Wl,-O1 -Wl,--sort-common -Wl,-Bdirect -Wl,-hashvals -Wl,-zdynsort -Wl,--as-needed Revert to a version of binutils from Gentoo and set your ldflags to this: -Wl,-O1,--as-needed I think that will fix the ltmain.sh errors as well.
My entire system is built with --as-needed and had no problems with imlib at all.
