GNOME Bugzilla – Bug 722480
LDFLAGS is ignored when running g-ir-scanner
Last modified: 2014-01-24 23:11:39 UTC
In gegl/Makefile.am, there is a line INTROSPECTION_SCANNER_ENV = CFLAGS= LDFLAGS= CXXFLAGS= which unset some variables set by the users. Users on FreeBSD may set LDFLAGS to "-L/usr/local/lib" or "-Wl,-Y/usr/local/lib", so ld can find libintl in /usr/local/lib. Unset LDFLAGS causes error on FreeBSD.
That line has a sordid history and removing it will only cause LDFLAGS to work if it is simultaneously set in both the environment and in configure. If you're seeing g-ir-scanner attempt to link "-lintl" it's getting that from an internal call to "pkg-config --libs gio-2.0 gmodule-2.0", it should have gotten the correct -L/foo from pkg-config.
Unsetting LDFLAGS does not cause problem if we use GLib installed in /usr/local. However, if we use GLib from JHBuild prefix, pkg-config will not provide needed -L/usr/local/lib and ld cannot find it.
This is really a bug in glib's .pc file, it's what brings in libintl adding that -L is its responsibility. g-ir-scanner can't be allowed to see those variables because it causes inconsistent builds based on the environment at the time "make" is run, unfortunately I don't see a clean way to allow you to add more flags to it. If you want to hack around it you can add the -L to the line with "Gegl_@GEGL_MAJOR_VERSION@_@GEGL_MINOR_VERSION@_gir_CFLAGS =". Those values are passed as arguments to g-ir-scanner and it understands -L and -l. However those are the only link flags it understands so I can't just append LDFLAGS to it blindly. Or if you have control of the .pc files you could add the -L to glib-2.0.pc where it belongs.
In my opinion it's actually incorrect to have -L flags in pkg-config if the libraries are in standard paths (including the paths in LDFLAGS). This is for a pretty good reason: -L is an LDFLAG and -l is an LDADD. If you mix these things (by having -L appear among the libraries) then things can go very badly off the rails simply because of the order that you list your $(gtk_LIBS) vs $(glib_LIBS) for example. That said, listing said -L flags is harmless, as long as projects get their use of LDFLAGS vs. LDADD/LIBADD correct because the LDADD/LIBADD are added by automake *after* the LDFLAGS, so the user's -L options in LDFLAGS will "win". This is really very important stuff -- it's what ensures you will link against the jhbuild version of the library instead of the system one... Consider the case where we have jhbuild prefix ~/jhbuild and libgtk thusly installed in ~/jhbuild/lib. We have another external library libfoo in /usr/local/lib. jhbuild in that case will properly be setting LDFLAGS in the environment to '-L~/jhbuild/lib'. For sake of argument there is also an older system version of libgtk installed. This is a pretty common scenario. If you go by pkg-config alone, even assuming that everyone sets -L properly in their pkg-config file and your Makefile looks like: my_LDADD = $(gtk_LIBS) $(foo_LIBS) then you will get this expanded to (summary approximation): my_LDADD = -L~/jhbuild/lib -lgtk -L/usr/local/lib -lfoo so far so good... but if you randomly happen to have it the other way around: my_LDADD = $(foo_LIBS) $(gtk_LIBS) then it will expand: my_LDADD = -L/usr/local/lib -lfoo -L~/jhbuild/lib -lgtk and therefore /usr/local/lib is in the install path before ~/jhbuild/lib and we will take the system version of Gtk. LDFLAGS, because it is added to the linker command line first, is the only way around this. It's really up to the build system of projects to properly respect LDFLAGS. This is done correctly by just about every other project in the GLib/Gtk/GNOME stack...
> This is done correctly by just about every other project in the GLib/Gtk/GNOME stack... The fact that it works doesn't mean there aren't interesting bugs hidden under it, I only noticed the issued because GEGL has a rather freaky CFLAGS value that causes g-ir-scanner to fail. And it will only see that value if CFLAGS is defined in the shell environment when you run "make" (not "configure", but "make"). Normal build commands do not use their environment, they pass the values of CLFAGS/LDFLAGS into the command as arguments as needed. g-ir-scanner is unique here in that it wants to see the environment variables. Or rather, our circumstance is unique in that it needs to see that value for it's pkg-config call to work. --- With regards to gtk’s pkg-config, I looked in my jhbuild installs and absolutely every pkg-config has -L${libdir} it. The issue with libintl is it has no pkg-config to depend on so gtk has to brute force it by appending the correct flags it it’s own.
(In reply to comment #5) > The fact that it works doesn't mean there aren't interesting bugs hidden under > it, I only noticed the issued because GEGL has a rather freaky CFLAGS value > that causes g-ir-scanner to fail. Did you file a bug against g-ir-scanner about this?
Per our IRC discussion I am going to look into passing some explicit values for the environment to g-ir-scanner.
See bug 722887, which should address the concerns that you raised on IRC. If I understood you correctly then after we apply that patch, you should be able to simply drop your use of INTROSPECTION_SCANNER_ENV.
Explicitly exporting the values seems to fix all issues. I believe the changes in bug 722887 are correct and will allow this line to be removed in the future. commit 449c994af3f74ea0d605fda654a53e239eb65ebd Author: Daniel Sabo <DanielSabo@gmail.com> Date: Fri Jan 24 07:33:15 2014 -0800 Always propagate the *FLAGS variables to g-ir-scanner (bug 722480) The issue was not that they got un-escaped too many times but too few. Expanding them here seems to get the correct behavior. gegl/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)