| Summary: | dev-scheme/guile-1.8.7: guile-config link reports CPPFLAGS and LDFLAGS it has been compiled with | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexis Ballier <aballier> |
| Component: | Current packages | Assignee: | Marijn Schouten (RETIRED) <hkbst> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | chris.burroughs, flameeyes, gnome-office+disabled, scheme, truedfx |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 335657 | ||
| Attachments: | trivial patch | ||
|
Description
Alexis Ballier
2007-12-14 00:16:15 UTC
Does this cause any problems? (In reply to comment #1) > Does this cause any problems? > no, not really, but for example, I cant compile any program that uses guile-config link to link to guile without as-needed if I compiled guile with it. Not a big issue but still a bug imho. Created attachment 138613 [details, diff]
trivial patch
patch is trivial enough, but it's probably wiser to ask upstream if this has been done by intention or not.
If reporting compile time ldflags in guile-config link is the wanted behavior, then close as invalid but that sucks. If its not wanted, then this patch should do it.
sent upstream Upstream says: "if `-L' flags are passed through `$LDFLAGS' to `configure', like `-L/path/to/gmp', then they must be reported by "guile-config link". Admittedly, it has the undesirable side-effect of reporting completely unrelated link flags as well. Unfortunately, I'm not sure we could reliably filter `$LDFLAGS'." -L stuff _in general_ should be reported through LIBS actually. But at any rate, you don't even _need_ -L stuff when linking guile unless you are not on an ELF system, so they could easily use that to decide whether to import the full of LDFLAGS or not. Or we could just fix it gentoo-side at least, as we know what is used to change libraries and what is just user configuration :) It also reports the CPPFLAGS it has been compiled with in pkg-config --cflags, but it does not report the CFLAGS there. And in my case, it does cause problems. I have emerge compile and link with extra flags that are not valid without a special specs file, so anything linking to guile outside of portage will complain about unrecognised compiler options. Actually, I only noticed this with guile 1.8.7; adjusting summary since it's possible that 1.8.3 did not record CPPFLAGS, which would make the summary confusing. Harald, do you have a patch that solves the issue for you? For the record, it was mandatory to workaround this at least for LDFLAGS in gnucash 2.4 [1] ebuild or a majority of tests would fail. [1] bug #346919 (In reply to comment #10) > For the record, it was mandatory to workaround this at least for LDFLAGS in > gnucash 2.4 [1] ebuild or a majority of tests would fail. > > [1] bug #346919 Guys, I want to ask stabilization of guile-1.8.8. Is there something you want me to do before that? Alexis patch is very simple, do you still want me to apply it? If it fixes what's reported by guile-config and by pkgconfig, then it would sure fit our needs. @@ -2,6 +2,13 @@ # Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2 # $Header: /var/cvsroot/gentoo-x86/dev-scheme/guile/ChangeLog,v 1.84 2011/04/29 09:44:07 pchrist Exp $ +*guile-1.8.8-r1 (29 Apr 2011) + + 29 Apr 2011; Panagiotis Christopoulos <pchrist@gentoo.org> + +guile-1.8.8-r1.ebuild, +files/guile-1.8.8-fix_guile-config.patch: + revbump, first try to fix bug #202205. Fix based on old patch from Alexis + Ballier (aballier) + This should be fixed in 1.8.8-r1. Please, test and report. I will soon file a stabilization request for 1.8.8-r1 if we don't have problems, and I'll do some cleanup of the whole directory/ebuilds. dev-scheme/guile-1.8.8-r1 has been stabled. Closing. |