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 615697 - Problems with Makefile
Problems with Makefile
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other Solaris
: Normal blocker
: 0.10.29
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-04-14 00:18 UTC by Brian Cameron
Modified: 2010-04-15 00:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for gst-plugins-base (958 bytes, patch)
2010-04-14 00:18 UTC, Brian Cameron
none Details | Review
patch for gst-plugins-good (1.38 KB, patch)
2010-04-14 00:18 UTC, Brian Cameron
none Details | Review

Description Brian Cameron 2010-04-14 00:18:09 UTC
Created attachment 158661 [details] [review]
patch for gst-plugins-base

When building GStreamer in 64-bit amd64 mode, I found that several examples would not build.  When we build GStreamer we set LDFLAGS to the following so it picks
up the right X11 libraries.

"-L/usr/X11/lib/amd64 -R/usr/X11/lib/amd64"

However, this fails when building several examples because the Makefile.am for several examples sets the libraries via foo_LDFLAGS.  Changing this to foo_LDADD fixes the problem.  This problem is caused because using the Sun linker, the libraries need to follow the -L arguments, and it gets constructed the wrong way when you use LDFLAGS.

Can this go upstream.

I had a similar problem in both gst-plugins-base and gst-plugins-good, and will attach both patches.
Comment 1 Brian Cameron 2010-04-14 00:18:35 UTC
Created attachment 158662 [details] [review]
patch for gst-plugins-good
Comment 2 Tim-Philipp Müller 2010-04-14 00:35:35 UTC
I've got a similar patch pending for core, for what it's worth.

So regarding the -base patch: why only those examples - don't the others have the same problem basically? (I guess it somehow doesn't matter there because they don't drag in other external libs?)
Comment 3 Brian Cameron 2010-04-14 00:42:15 UTC
The linker only cares about linking in libraries when it is actually building a binary.  When building a shared object, for example, it doesn't require that the libraries actually resolve.  I only needed to make this change for examples that directly link against X11 libraries.
Comment 4 Sebastian Dröge (slomo) 2010-04-14 04:56:49 UTC
The other examples need fixing too IMHO, at least for cosmetic reasons ;) LDFLAGS should only contain linker flags while LIBADD/LDADD should contain the libraries.
Comment 5 Tim-Philipp Müller 2010-04-15 00:58:21 UTC
commit b5f0b7c2210d5a813df68b34dcc1af89beeb68a8
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Wed Apr 14 13:43:44 2010 +0100

    build: use LDADD instead of LDFLAGS to specify libs to link to when building executables
    
    Use foo_LDADD instead of foo_LDFLAGS to specify the libraries to link to.
    This should make sure arguments are passed to the linker in the right
    order, and makes LDFLAGS usable again.
    
    Based on initial patch by Brian Cameron <brian.cameron@oracle.com>
    
    Fixes #615697.


commit cc04850bd89680a2a71e9b1174c9b5a21f13e37a
Author: Tim-Philipp Müller <tim.muller@collabora.co.uk>
Date:   Wed Apr 14 20:06:09 2010 +0100

    tests: use LDADD for libs to link to instead of LDFLAGS
    
    Use foo_LDADD instead of foo_LDFLAGS to specify the libraries to link to.
    This should make sure arguments are passed to the linker in the right
    order, and makes LDFLAGS usable again.
    
    Based on patch by Brian Cameron <brian.cameron@oracle.com>
    
    Fixes #615697.