I'm reporting this bug because the package in summary fails to build when forcing --as-needed on through spec files (check out http://blog.flameeyes.eu/2008/11/14/problems-and-mitigation-strategies-for-as-needed for details). Please note that this bug _might_ apply to -Wl,--as-needed in LDFLAGS as well; in both cases it should be fixed. Also, if this is due to the package in question not respecting user-defined LDFLAGS, you should get to fix that too. Check the attached build log. Thanks, Diego
Created attachment 174556 [details] Build log
to me it just looks like it fails to compile regardless of as-needed, or am I missing something?
If you look at the linking line: i686-pc-linux-gnu-gcc -rdynamic -LFrameworks/Cynthiune/Cynthiune.framework/Versions/Current -lCynthiune ... -lCynthiune is passed before any object file. I think it's what Bernard referred to in bug #249507 as ADDITIONAL_*. This seems to be common for other packages too, so it should probably be fixed in the same way across the ebuilds.
ahh, let me see what I can do about that.
problem with Cynthiune is that it is a framework, so the offending "lib" is a framework, not a library. They add this to the LDFLAGS: frameworks.make: ifeq (mingw32, $(GNUSTEP_TARGET_OS)) ADDITIONAL_GUI_LIBS += -L$(FRAMEWORKS_DIRS)/../../Cynthiune.app $(_ldflags) else ADDITIONAL_LDFLAGS += $(_ldflags) endif Perhaps we could slightly hack in this case such that the -lCynthiune goes in ADDITIONAL_GUI_LIBS, while the rest goes in ADDITIONAL_LDFLAGS. I suspect upstream is not going to be amused. Your log shows it's been done right through the system, and only fails for this framework thing.
Indeed that looks the correct way to clean this. I've split $(_ldflags) in $(_ldflags) and $(_libs), added to revbumped ebuild just in case it breaks something ;) Upstream looks mostly dead (I hope melodie becomes useful before we can't maintain this one anymore)
