After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 722480 - LDFLAGS is ignored when running g-ir-scanner
LDFLAGS is ignored when running g-ir-scanner
Product: GEGL
Classification: Other
Component: general
git master
Other FreeBSD
: Normal normal
: ---
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on: 722887
Reported: 2014-01-18 07:22 UTC by Ting-Wei Lan
Modified: 2014-01-24 23:11 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Ting-Wei Lan 2014-01-18 07:22:45 UTC
In gegl/, there is a line

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.
Comment 1 Daniel Sabo 2014-01-18 09:55:19 UTC
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.
Comment 2 Ting-Wei Lan 2014-01-18 11:36:17 UTC
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.
Comment 3 Daniel Sabo 2014-01-18 12:44:56 UTC
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.
Comment 4 Allison Karlitskaya (desrt) 2014-01-23 07:04:55 UTC
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...
Comment 5 Daniel Sabo 2014-01-23 16:12:53 UTC
> This is done correctly by just about every other project in the GLib/Gtk/GNOME

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.
Comment 6 Allison Karlitskaya (desrt) 2014-01-23 16:30:53 UTC
(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?
Comment 7 Daniel Sabo 2014-01-24 02:03:54 UTC
Per our IRC discussion I am going to look into passing some explicit values for the environment to g-ir-scanner.
Comment 8 Allison Karlitskaya (desrt) 2014-01-24 04:41:27 UTC
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.
Comment 9 Daniel Sabo 2014-01-24 23:11:39 UTC
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 <>
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/ | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)