LDFLAGS setting in buildroot

[Daniel J Laird]

Sometime ago Thomas Petazzoni posted some patches about setting rpath-link etc.

I have been playing with this and have come to similar conclusion. That is that
doing LD="$(TARGET_LD) $(TARGET_LDFLAGS)" is not very helpful.

In fact if I do this I need to pass LDFLAGS to lots of my packages
directfb
png,
webkit,
cairo,
To name but a few.

However if I split this into:
LD="$(TARGET_LD)"
LDFLAGS="$(TARGET_LDFLAGS)"

They all build better (i.e I do not need to add LD_FLAGS to all the packages) and I can then add --rpath-link lines to TARGET_LDFLAGS and they all still build (no shared library issues)
Does anyone have any problems with what I am suggesting before I go ahead and commit.....

Many thanks
Daniel Laird

[Bernhard Reutner-Fischer]

Post by Daniel J Laird
Does anyone have any problems with what I am suggesting before I go ahead and commit.....

See very end of
http://busybox.net/lists/buildroot/2008-October/011313.html

[Thomas Petazzoni]

Le Tue, 28 Oct 2008 14:18:17 +0100,

Post by Bernhard Reutner-Fischer

Post by Daniel J Laird
Does anyone have any problems with what I am suggesting before I go ahead and commit.....

See very end of
http://busybox.net/lists/buildroot/2008-October/011313.html

I'm sorry, but I don't see the relationship between the technical issue
raised by Daniel and the e-mail you're pointing to. Or maybe I
misunderstood, and you're not discussion the technical issue but rather
the integration process ?

Thanks,

Thomas

[Bernhard Reutner-Fischer]

Post by Thomas Petazzoni
Le Tue, 28 Oct 2008 14:18:17 +0100,

Post by Bernhard Reutner-Fischer

Post by Daniel J Laird
Does anyone have any problems with what I am suggesting before I go
ahead and commit.....

See very end of
http://busybox.net/lists/buildroot/2008-October/011313.html

I'm sorry, but I don't see the relationship between the technical issue
raised by Daniel and the e-mail you're pointing to. Or maybe I

Did you read the hunk i pointed at?

Post by Thomas Petazzoni
misunderstood, and you're not discussion the technical issue but rather
the integration process ?

I'm talking about technical issues you are having and how to tackle them
properly.

[Thomas Petazzoni]

Le Tue, 28 Oct 2008 14:45:55 +0100,

Post by Bernhard Reutner-Fischer

Post by Thomas Petazzoni
I'm sorry, but I don't see the relationship between the technical
issue raised by Daniel and the e-mail you're pointing to. Or maybe I

Did you read the hunk i pointed at?

Yes I did, but didn't get that « my tree » was a reference to your Git
tree. Where is it located, again ?

It's a shame that the Buildroot development is split between the
Subversion tree and your Git tree. Both of them carry useful stuff.

Was the move to a personal Git tree motivated by the use of Git as a
tool, or by the integration process of patches in Buildroot SVN ? How
can we progress to unify the project again, if possible ?

Thomas

[Bernhard Reutner-Fischer]

Post by Thomas Petazzoni
can we progress to unify the project again, if possible ?

Anybody is invited to transfer my changes back to the svn tree. I
deliberately didn't hide it away.

HTH,

[Thomas Petazzoni]

Le Tue, 28 Oct 2008 16:31:00 +0100,

Post by Bernhard Reutner-Fischer

Post by Thomas Petazzoni
can we progress to unify the project again, if possible ?

Anybody is invited to transfer my changes back to the svn tree. I
deliberately didn't hide it away.

By saying this, you're declining the idea of contributing again to the
main Buildroot tree ?

Where's located your Git tree again ?

Thanks!

Thomas

[Nick Peirson]

Post by Thomas Petazzoni
Where's located your Git tree again

I presume it's:
http://repo.or.cz/w/buildroot.git

Google is your friend! :c)

[Bernhard Reutner-Fischer]

Post by Thomas Petazzoni
By saying this, you're declining the idea of contributing again to the
main Buildroot tree ?

I constantly do but i will not put stuff back into the svn tree anytime
soon. Feel free to work with jacmet to bring svn back in sync.

Post by Thomas Petazzoni
Where's located your Git tree again ?

http://www.google.com/search?num=2&hl=en&as_qdr=all&q=buildroot+git+tree&btnG=Search

[Steffen Schulz]

Post by Bernhard Reutner-Fischer

Post by Thomas Petazzoni
By saying this, you're declining the idea of contributing again to the
main Buildroot tree ?

I constantly do but i will not put stuff back into the svn tree anytime
soon. Feel free to work with jacmet to bring svn back in sync.

So...without blaming anyone for anything here...


Do you accept and merge patches in finite time, and without them
sitting around in the bug tracking system for a few months?

Or what is this about?


/steffen

[Daniel J Laird]

Thanks for the link. It looks like we want to start merging the AUTO_CONFIGURE_TARGET, the only downside at the moment is this is only used for Makefile.autotools.in stuff so I would need to do some changes to make it useful for directfb.mk for example.

I will have a look at the rest of these changes as well

Dan

[Bernhard Reutner-Fischer]

Post by Daniel J Laird
Thanks for the link. It looks like we want to start merging the AUTO_CONFIGURE_TARGET, the only downside at the moment is this is only used for Makefile.autotools.in stuff so I would need to do some changes to make it useful for directfb.mk for example.

This is not entirely true. grep AUTO_CONFIGURE_TARGET package/*/*.mk

[Daniel J Laird]

Agreed, I would need to do for directfb.mk what you have done is lots of other packages.....

I think I will look into adding your stuff and see where that gets me.

Cheers
Dan

[Daniel J Laird]

I have been playing with using the AUTO_CONFIGURE_TARGET and it seems to be going faster as you indicated but I have discovered an issue.

I build a number of packages and as each one builds they update the central cache file.
However One of my packages configures before zlib is built.
This means it caches zlib is unavailable.

directfb then tries to build and it checks for zlib and returns
zlib.h not found...(cached)

Do you see such issues as I cannot see how to make the cache file update with correct values after it has been told something does not exist.

Many thanks
Daniel Kaird

[Peter Korsgaard]

Daniel> I have been playing with using the AUTO_CONFIGURE_TARGET and it seems to be going faster as you indicated but I have discovered an issue.
Daniel> I build a number of packages and as each one builds they update the central cache file.
Daniel> However One of my packages configures before zlib is built.
Daniel> This means it caches zlib is unavailable.

Shouldn't that package then depend on zlib?

[Daniel Laird]

Yes, I agree. in this case freetype was not dependant upon zlib and it
looks for it in configure so I added that dependancy and it works fine.....

-----Original Message-----
From: buildroot-bounces-2zL2ArBv0bUdnm+***@public.gmane.org [mailto:buildroot-bounces-2zL2ArBv0bUdnm+***@public.gmane.org] On
Behalf Of Peter Korsgaard
Sent: 2008 Oct 29 14:11
To: Daniel J Laird
Cc: buildroot-2zL2ArBv0bUdnm+***@public.gmane.org
Subject: Re: [Buildroot] LDFLAGS setting in buildroot
Daniel> I have been playing with using the AUTO_CONFIGURE_TARGET and it
seems to be going faster as you indicated but I have discovered an issue.
Daniel> I build a number of packages and as each one builds they update
the central cache file.
Daniel> However One of my packages configures before zlib is built.
Daniel> This means it caches zlib is unavailable.

Shouldn't that package then depend on zlib?

[Bernhard Reutner-Fischer]

Post by Daniel J Laird
I have been playing with using the AUTO_CONFIGURE_TARGET and it seems to be going faster as you indicated but I have discovered an issue.

heh. I said "at least".

Post by Daniel J Laird
I build a number of packages and as each one builds they update the central cache file.
However One of my packages configures before zlib is built.

broken package. Fix it's dependencies.

Post by Daniel J Laird
Do you see such issues as I cannot see how to make the cache file update with correct values after it has been told something does not exist.

This is strictly forbidden.

[Daniel J Laird]

I have read the hunk pointed at and am slightly confused.
Is there another buildroot tree (your tree) that does things better than the buildroot tree hosted at buildroot.org?

If so what is its location? As I am always interested in improvements...

Secondly I am using buildroot in an existing build system so switching away from buildroot is not going to happen so perhaps we can start to move the good stuff from your tree over?

The alternative is to take the patches I have proposed because although not perfect I believe they improve the current buildroot tree.

Many thanks
Daniel Laird

[Daniel J Laird]

The proposed patch would be something like this:

--- buildroot/SVN/buildroot/package/Makefile.in
+++ buildroot/SVN/buildroot.new/package/Makefile.in
@@ -39,7 +39,7 @@
ifeq ($(BR2_TOOLCHAIN_SOURCE),y)
TARGET_CFLAGS=$(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING) \
-I$(STAGING_DIR)/usr/include -I$(STAGING_DIR)/include
-TARGET_LDFLAGS+=-L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib
+TARGET_LDFLAGS+=-L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib -Wl,--rpath-link -Wl,$(STAGING_DIR)/lib -Wl,--rpath-link -Wl,$(STAGING_DIR)/usr/lib
ifeq ($(BR2_TOOLCHAIN_SYSROOT),y)
TARGET_CFLAGS+= $(BR2_SYSROOT) $(BR2_ISYSROOT)
TARGET_LDFLAGS+= $(BR2_SYSROOT)
@@ -91,7 +91,7 @@
else
TARGET_CFLAGS=$(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING) -I$(STAGING_DIR)/include -I$(STAGING_DIR)/usr/include -I$(TOOLCHAIN_EXTERNAL_PATH)/$(TOOLCHAIN_EXTERNAL_PREFIX)/include
TARGET_CXXFLAGS=$(TARGET_CFLAGS)
-TARGET_LDFLAGS=-L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib
+TARGET_LDFLAGS+=-L$(STAGING_DIR)/lib -L$(STAGING_DIR)/usr/lib -Wl,--rpath-link -Wl,$(STAGING_DIR)/lib -Wl,--rpath-link -Wl,$(STAGING_DIR)/usr/lib
endif
#########################################################################
#ifeq ($(BR2_ROOTFS_SUFFIX),)
@@ -126,7 +126,8 @@
#"))
#TOOL_BUILD_DIR=$(BASE_DIR)/$(TOPDIR_PREFIX)toolchain_build_$(TOOLCHAIN_EXTERNAL_PREFIX)
TOOL_BUILD_DIR=$(BASE_DIR)/$(TOPDIR_PREFIX)toolchain_build_$(ARCH)$(COND_ARCH_FPU_SUFFIX)$(TOPDIR_SUFFIX)
-TARGET_PATH="$(STAGING_DIR)/bin:$(TOOL_BUILD_DIR)/bin:$(TOOLCHAIN_EXTERNAL_PATH)/bin:$(PATH)"
+# Make sure that STAGING_DIR/usr/bin is in path for freetype-config etc.
+TARGET_PATH="$(STAGING_DIR)/usr/bin:$(STAGING_DIR)/bin:$(TOOL_BUILD_DIR)/bin:$(TOOLCHAIN_EXTERNAL_PATH)/bin:$(PATH)"
#IMAGE:=$(BINARIES_DIR)/$(BR2_ROOTFS_PREFIX).$(TOOLCHAIN_EXTERNAL_PREFIX)$(ROOTFS_SUFFIX)
IMAGE:=$(BINARIES_DIR)/$(BR2_ROOTFS_PREFIX).$(ARCH)$(COND_ARCH_FPU_SUFFIX)$(ROOTFS_SUFFIX)

@@ -196,7 +197,8 @@
TARGET_CONFIGURE_OPTS=PATH=$(TARGET_PATH) \
AR="$(TARGET_AR)" \
AS="$(TARGET_AS)" \
- LD="$(TARGET_LD) $(TARGET_LDFLAGS)" \
+ LD="$(TARGET_LD)" \
+ LDFLAGS="$(TARGET_LDFLAGS)" \
NM="$(TARGET_NM)" \
CC="$(TARGET_CC) $(TARGET_CFLAGS)" \
GCC="$(TARGET_CC) $(TARGET_CFLAGS)" \

Let me know your thoughts

[Thomas Petazzoni]

Le Tue, 28 Oct 2008 14:58:19 +0100,
I confirm that this patch works for me, I was able to build Gtk +
DirectFB with all their dependencies properly.

Acked-By: Thomas Petazzoni <***@free-electrons.com>

Sincerly,

Thomas

[Thomas Petazzoni]

Le Tue, 28 Oct 2008 23:20:24 +0100,

Post by Thomas Petazzoni
I confirm that this patch works for me, I was able to build Gtk +
DirectFB with all their dependencies properly.

The patch also seems to solve http://busybox.net/bugs/view.php?id=5714.

Thomas

[Thomas Petazzoni]

Le Tue, 28 Oct 2008 13:36:08 +0100,

Post by Daniel J Laird
Sometime ago Thomas Petazzoni posted some patches about setting rpath-link etc.
I have been playing with this and have come to similar conclusion.
That is that doing LD="$(TARGET_LD) $(TARGET_LDFLAGS)" is not very
helpful.

It's worse than that: on my setup, the patch you committed didn't work
because the -Wl,--rpath-link option was in TARGET_LDFLAGS, and so was
part of the LD variable, leading to ./configure failures when trying to
detect available libraries.

Post by Daniel J Laird
They all build better (i.e I do not need to add LD_FLAGS to all the
packages) and I can then add --rpath-link lines to TARGET_LDFLAGS and
they all still build (no shared library issues) Does anyone have any
problems with what I am suggesting before I go ahead and commit.....

Can you just send the patch you intend to commit, so that I can test
before ?

Thanks a lot for caring about this issue !

Cheers,

Thomas