[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[sjhill at uclibc.org]

Author: sjhill
Date: 2007-04-18 19:04:15 -0700 (Wed, 18 Apr 2007)
New Revision: 18495

Log:
Some 'find' commands get a little picky.


Modified:
   trunk/buildroot/toolchain/external-toolchain/ext-tool.mk


Changeset:
Modified: trunk/buildroot/toolchain/external-toolchain/ext-tool.mk
===================================================================
--- trunk/buildroot/toolchain/external-toolchain/ext-tool.mk	2007-04-19 00:09:34 UTC (rev 18494)
+++ trunk/buildroot/toolchain/external-toolchain/ext-tool.mk	2007-04-19 02:04:15 UTC (rev 18495)
@@ -18,7 +18,7 @@
 	fi;											\
 												\
 	LIB="$(strip $1)";									\
-	for FILE in `find $${LIB_DIR} -type l -name "$${LIB}*" -maxdepth 1`; do			\
+	for FILE in `find $${LIB_DIR} -maxdepth 1 -type l -name "$${LIB}*"`; do			\
 		LIB=`basename $${FILE}`;							\
 		while test \! -z "$${LIB}"; do							\
 			echo "copy_toolchain_lib_root lib=$${LIB} dst=$${DST}";			\

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[sjhill at uclibc.org]

Author: sjhill
Date: 2007-04-28 10:10:31 -0700 (Sat, 28 Apr 2007)
New Revision: 18529

Log:
When using an external toolchain, we still need to have the user select which thread model the toolchain was built with. This allows for proper building of LTP and possibly other packages.


Modified:
   trunk/buildroot/toolchain/external-toolchain/Config.in


Changeset:
Modified: trunk/buildroot/toolchain/external-toolchain/Config.in
===================================================================
--- trunk/buildroot/toolchain/external-toolchain/Config.in	2007-04-28 17:09:44 UTC (rev 18528)
+++ trunk/buildroot/toolchain/external-toolchain/Config.in	2007-04-28 17:10:31 UTC (rev 18529)
@@ -27,10 +27,10 @@
 	help
 	  Strip shared libraries copied from the external toolchain.
 
+comment "Common Toolchain Options"
+
 source "toolchain/gdb/Config.in.2"
 
-comment "Common Toolchain Options"
-
 config BR2_TOOLCHAIN_EXTERNAL_PATH
 	string "External toolchain path"
 	default ""
@@ -44,6 +44,29 @@
 	  This the the external toolchain prefix. For example:
 	    armeb-unknown-linux-gnu, mipsel-unknown-linux-gnu, etc.
 
+choice
+	prompt "Thread library implementation"
+	default BR2_EXT_PTHREADS_OLD
+	help
+	  Select the version of libpthreads used in the external toolchain.
+
+	config BR2_EXT_PTHREADS_NONE
+		bool
+		prompt "none"
+
+	config BR2_EXT_PTHREADS
+		bool
+		prompt "linuxthreads"
+
+	config BR2_EXT_PTHREADS_OLD
+		bool
+		prompt "linuxthreads (stable/old)"
+
+	config BR2_EXT_PTHREADS_NATIVE
+		bool
+		prompt "Native POSIX Threading (NPTL)"
+endchoice
+
 config BR2_LARGEFILE
 	bool "Enable large file (files > 2 GB) support?"
 	depends on !BR2_cris

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[sjhill at uclibc.org]

Author: sjhill
Date: 2007-07-16 17:18:54 -0700 (Mon, 16 Jul 2007)
New Revision: 19115

Log:
Allow selection of RPC and IPv6 options for an external toolchain.


Modified:
   trunk/buildroot/toolchain/external-toolchain/Config.in


Changeset:
Modified: trunk/buildroot/toolchain/external-toolchain/Config.in
===================================================================
--- trunk/buildroot/toolchain/external-toolchain/Config.in	2007-07-16 22:21:15 UTC (rev 19114)
+++ trunk/buildroot/toolchain/external-toolchain/Config.in	2007-07-17 00:18:54 UTC (rev 19115)
@@ -74,6 +74,18 @@
 	help
 	  Enable large file (files > 2 GB) support
 
+config BR2_INET_IPV6
+	bool "Enable IPv6"
+	default n
+	help
+	    Enable IPv6.
+
+config BR2_INET_RPC
+	bool "Enable RPC"
+	default n
+	help
+	    Enable RPC. RPC support is needed for nfs.
+
 config BR2_SOFT_FLOAT
 	bool "Use software floating point by default"
 	default n

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[jacmet at uclibc.org]

Author: jacmet
Date: 2008-06-16 05:22:45 -0700 (Mon, 16 Jun 2008)
New Revision: 22378

Log:
toolchain: more sensible uclibc defaults for external toolchain


Modified:
   trunk/buildroot/toolchain/external-toolchain/Config.in


Changeset:
Modified: trunk/buildroot/toolchain/external-toolchain/Config.in
===================================================================
--- trunk/buildroot/toolchain/external-toolchain/Config.in	2008-06-16 11:42:19 UTC (rev 22377)
+++ trunk/buildroot/toolchain/external-toolchain/Config.in	2008-06-16 12:22:45 UTC (rev 22378)
@@ -6,7 +6,7 @@
 
 config BR2_TOOLCHAIN_EXTERNAL_LIB_C
 	string "The core C library from the external toolchain"
-	default "libc.so.6"
+	default "libc.so.0"
 	help
 	  Specify the core C shared library found in the external
 	  toolchain. This is required in addition to any other
@@ -14,7 +14,7 @@
 
 config BR2_TOOLCHAIN_EXTERNAL_LIBS
 	string "Libraries to copy from the external toolchain"
-	default ""
+	default "ld-uClibc.so.0 libcrypt.so.0 libdl.so.0 libgcc_s.so libm.so.0 libnsl.so.0 libpthread.so.0 libresolv.so.0 librt.so.0 libutil.so.0"
 	help
 	  A space separated list of the shared libraries to be copied
 	  from the external toolchain into the root filesystem. Only
@@ -34,13 +34,13 @@
 
 config BR2_TOOLCHAIN_EXTERNAL_PATH
 	string "External toolchain path"
-	default ""
+	default "/path/to/staging_dir/usr"
 	help
 	  Path to where the external toolchain is installed.
 
 config BR2_TOOLCHAIN_EXTERNAL_PREFIX
 	string "External toolchain prefix"
-	default ""
+	default "$(ARCH)-linux"
 	help
 	  This the the external toolchain prefix. For example:
 	    armeb-unknown-linux-gnu, mipsel-unknown-linux-gnu, etc.

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Bernhard Fischer]

On Mon, Jun 16, 2008 at 05:22:46AM -0700, jacmet at uclibc.org wrote:
>Author: jacmet
>Date: 2008-06-16 05:22:45 -0700 (Mon, 16 Jun 2008)
>New Revision: 22378
>
>Log:
>toolchain: more sensible uclibc defaults for external toolchain

Note that the external toolchain always defaulted to use a glibc-based
toolchain. Steven should be notified on such a change since (IIRC) it
was him who added the external-toolchain thing..

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Peter Korsgaard]

>>>>> "Bernhard" == Bernhard Fischer <rep.dot.nop@gmail.com> writes:

Hi,

 >> Author: jacmet
 >> Date: 2008-06-16 05:22:45 -0700 (Mon, 16 Jun 2008)
 >> New Revision: 22378
 >> 
 >> Log:
 >> toolchain: more sensible uclibc defaults for external toolchain

 Bernhard> Note that the external toolchain always defaulted to use a
 Bernhard> glibc-based toolchain. Steven should be notified on such a
 Bernhard> change since (IIRC) it was him who added the
 Bernhard> external-toolchain thing..

He afaiks reads this list as well, and it's just defaults, so no big
deal. BR2_TOOLCHAIN_EXTERNAL_LIBS, BR2_TOOLCHAIN_EXTERNAL_PATH and
BR2_TOOLCHAIN_EXTERNAL_PREFIX weren't set to anything before, so glibc
users have to configure it anyway.

We might as well default to something that is right away usable for
buildroot users.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Bernhard Fischer]

On Mon, Jun 16, 2008 at 04:07:36PM +0200, Peter Korsgaard wrote:
>>>>>> "Bernhard" == Bernhard Fischer <rep.dot.nop@gmail.com> writes:
>
>Hi,
>
> >> Author: jacmet
> >> Date: 2008-06-16 05:22:45 -0700 (Mon, 16 Jun 2008)
> >> New Revision: 22378
> >> 
> >> Log:
> >> toolchain: more sensible uclibc defaults for external toolchain
>
> Bernhard> Note that the external toolchain always defaulted to use a
> Bernhard> glibc-based toolchain. Steven should be notified on such a
> Bernhard> change since (IIRC) it was him who added the
> Bernhard> external-toolchain thing..
>
>He afaiks reads this list as well, and it's just defaults, so no big
>deal. BR2_TOOLCHAIN_EXTERNAL_LIBS, BR2_TOOLCHAIN_EXTERNAL_PATH and
>BR2_TOOLCHAIN_EXTERNAL_PREFIX weren't set to anything before, so glibc
>users have to configure it anyway.

It would be nice if you would list example values in the help-text for a
few libc's then (i did not look if you already do this).

>
>We might as well default to something that is right away usable for
>buildroot users.

.. which would be everything but external toolchain, yes ;)

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Hamish Moffatt]

On Mon, Jun 16, 2008 at 05:22:46AM -0700, jacmet at uclibc.org wrote:
>  config BR2_TOOLCHAIN_EXTERNAL_PATH
>  	string "External toolchain path"
> -	default ""
> +	default "/path/to/staging_dir/usr"
>  	help
>  	  Path to where the external toolchain is installed.

I've set this to "$(BR2_STAGING_DIR)/usr" here, which might be a good
default?

>  config BR2_TOOLCHAIN_EXTERNAL_PREFIX
>  	string "External toolchain prefix"
> -	default ""
> +	default "$(ARCH)-linux"
>  	help
>  	  This the the external toolchain prefix. For example:
>  	    armeb-unknown-linux-gnu, mipsel-unknown-linux-gnu, etc.

Probably not a useful default, given that all the examples have -gnu etc
after them? Mine is armeb-linux-uclibcgnu here; again you can probably
construct something like "$(ARCH)-$(BR2_GNU_TARGET_SUFFIX)".


thanks
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 Hamish> On Mon, Jun 16, 2008 at 05:22:46AM -0700, jacmet at uclibc.org wrote:
 >> config BR2_TOOLCHAIN_EXTERNAL_PATH
 >> string "External toolchain path"
 >> -	default ""
 >> +	default "/path/to/staging_dir/usr"
 >> help
 >> Path to where the external toolchain is installed.

 Hamish> I've set this to "$(BR2_STAGING_DIR)/usr" here, which might
 Hamish> be a good default?

You think so? I wouldn't expect having buildroot install package stuff
together with the (potentially read only) external toolchain would be
a common setup.

 >> config BR2_TOOLCHAIN_EXTERNAL_PREFIX
 >> string "External toolchain prefix"
 >> -	default ""
 >> +	default "$(ARCH)-linux"
 >> help
 >> This the the external toolchain prefix. For example:
 >> armeb-unknown-linux-gnu, mipsel-unknown-linux-gnu, etc.

 Hamish> Probably not a useful default, given that all the examples
 Hamish> have -gnu etc after them? Mine is armeb-linux-uclibcgnu here;
 Hamish> again you can probably construct something like
 Hamish> "$(ARCH)-$(BR2_GNU_TARGET_SUFFIX)".

Don't you have an armeb-linux symlink? For the stuff I compile (arm,
i386, ppc) there's symlinks from the arm-linux-uclibc-<whatever> to
arm-linux-<whatever>.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Hamish Moffatt]

On Tue, Jun 17, 2008 at 09:16:43AM +0200, Peter Korsgaard wrote:
>  Hamish> On Mon, Jun 16, 2008 at 05:22:46AM -0700, jacmet at uclibc.org wrote:
>  >> config BR2_TOOLCHAIN_EXTERNAL_PATH
>  >> string "External toolchain path"
>  >> -	default ""
>  >> +	default "/path/to/staging_dir/usr"
>  >> help
>  >> Path to where the external toolchain is installed.
> 
>  Hamish> I've set this to "$(BR2_STAGING_DIR)/usr" here, which might
>  Hamish> be a good default?
> 
> You think so? I wouldn't expect having buildroot install package stuff
> together with the (potentially read only) external toolchain would be
> a common setup.

Well I've got one board ("tools", in local/tools/tools.config) to build
the toolchain which I then use as external toolchain to build several
other boards (all armeb-linux-uclibcgnu). So my toolchain lives in the
staging directory in the same tree.

This makes for a nice path-independent setup too.. other developers at
my company can check out the tree and build everything (including the
toolchain first) into any path they like.

So if this isn't a common approach then maybe it isn't a good default
after all.

> Don't you have an armeb-linux symlink? For the stuff I compile (arm,
> i386, ppc) there's symlinks from the arm-linux-uclibc-<whatever> to
> arm-linux-<whatever>.

Probably, I'll have to check tomorrow.

thanks
Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 Hamish> I've set this to "$(BR2_STAGING_DIR)/usr" here, which might
 Hamish> be a good default?
 >> 
 >> You think so? I wouldn't expect having buildroot install package stuff
 >> together with the (potentially read only) external toolchain would be
 >> a common setup.

 Hamish> Well I've got one board ("tools", in
 Hamish> local/tools/tools.config) to build the toolchain which I then
 Hamish> use as external toolchain to build several other boards (all
 Hamish> armeb-linux-uclibcgnu). So my toolchain lives in the staging
 Hamish> directory in the same tree.

So they all put libraries / headers in the same staging_dir? Doesn't
that give problems with packages detecting optional stuff at compile
time that might not be available for a specific variant (E.G. one
variant has expat, and another doesn't - Some configure script checks
for expat and finds it in staging_dir even though it isn't going to be
there at runtime).

The same with the packages offering different versions.

I think a more common setup would be to install the toolchain
somewhere common (/opt/<whatever>) and then have multiple boards using
the same toolchain/c library but potentially different set of
packages(-versions) and their own staging_dir.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Bernhard Fischer]

On Tue, Jun 17, 2008 at 03:45:04PM +0200, Peter Korsgaard wrote:
>>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:
>
>Hi,
>
> Hamish> I've set this to "$(BR2_STAGING_DIR)/usr" here, which might
> Hamish> be a good default?
> >> 
> >> You think so? I wouldn't expect having buildroot install package stuff
> >> together with the (potentially read only) external toolchain would be
> >> a common setup.
>
> Hamish> Well I've got one board ("tools", in
> Hamish> local/tools/tools.config) to build the toolchain which I then
> Hamish> use as external toolchain to build several other boards (all
> Hamish> armeb-linux-uclibcgnu). So my toolchain lives in the staging
> Hamish> directory in the same tree.
>
>So they all put libraries / headers in the same staging_dir? Doesn't
>that give problems with packages detecting optional stuff at compile
>time that might not be available for a specific variant (E.G. one
>variant has expat, and another doesn't - Some configure script checks
>for expat and finds it in staging_dir even though it isn't going to be
>there at runtime).
>
>The same with the packages offering different versions.
>
>I think a more common setup would be to install the toolchain
>somewhere common (/opt/<whatever>) and then have multiple boards using
>the same toolchain/c library but potentially different set of
>packages(-versions) and their own staging_dir.

If i understand correctly what you are talking about then this is
exactly the purpose of that PROJECT thing, fwiw.

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Peter Korsgaard]

>>>>> "Bernhard" == Bernhard Fischer <rep.dot.nop@gmail.com> writes:

Hi,

 >> So they all put libraries / headers in the same staging_dir? Doesn't
 >> that give problems with packages detecting optional stuff at compile
 >> time that might not be available for a specific variant (E.G. one
 >> variant has expat, and another doesn't - Some configure script checks
 >> for expat and finds it in staging_dir even though it isn't going to be
 >> there at runtime).
 >> 
 >> The same with the packages offering different versions.
 >> 
 >> I think a more common setup would be to install the toolchain
 >> somewhere common (/opt/<whatever>) and then have multiple boards using
 >> the same toolchain/c library but potentially different set of
 >> packages(-versions) and their own staging_dir.

 Bernhard> If i understand correctly what you are talking about then this is
 Bernhard> exactly the purpose of that PROJECT thing, fwiw.

Me? No, the project stuff is (afaik atleast) just about compiling the
configurable packages under project_build_* instead of build_*, so you
can reuse a single working directory / staging_dir for multiple
projects. It has the same drawbacks as what I listed above.

It does sound pretty much what Hamish is doing though.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Bernhard Fischer]

On Tue, Jun 17, 2008 at 04:55:34PM +0200, Peter Korsgaard wrote:
>>>>>> "Bernhard" == Bernhard Fischer <rep.dot.nop@gmail.com> writes:
>
>Hi,
>
> >> So they all put libraries / headers in the same staging_dir? Doesn't
> >> that give problems with packages detecting optional stuff at compile
> >> time that might not be available for a specific variant (E.G. one
> >> variant has expat, and another doesn't - Some configure script checks
> >> for expat and finds it in staging_dir even though it isn't going to be
> >> there at runtime).
> >> 
> >> The same with the packages offering different versions.
> >> 
> >> I think a more common setup would be to install the toolchain
> >> somewhere common (/opt/<whatever>) and then have multiple boards using
> >> the same toolchain/c library but potentially different set of
> >> packages(-versions) and their own staging_dir.
>
> Bernhard> If i understand correctly what you are talking about then this is
> Bernhard> exactly the purpose of that PROJECT thing, fwiw.
>
>Me?

no, Hamish.

>    No, the project stuff is (afaik atleast) just about compiling the
>configurable packages under project_build_* instead of build_*, so you
>can reuse a single working directory / staging_dir for multiple
>projects. It has the same drawbacks as what I listed above.
>
>It does sound pretty much what Hamish is doing though.

Exactly.

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Hamish Moffatt]

On Tue, Jun 17, 2008 at 08:47:54PM +1000, Hamish Moffatt wrote:
> On Tue, Jun 17, 2008 at 09:16:43AM +0200, Peter Korsgaard wrote:
> > Don't you have an armeb-linux symlink? For the stuff I compile (arm,
> > i386, ppc) there's symlinks from the arm-linux-uclibc-<whatever> to
> > arm-linux-<whatever>.
> 
> Probably, I'll have to check tomorrow.

Indeed I do have an armeb-linux symlink.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Hamish Moffatt]

On Tue, Jun 17, 2008 at 03:45:04PM +0200, Peter Korsgaard wrote:
>  Hamish> Well I've got one board ("tools", in
>  Hamish> local/tools/tools.config) to build the toolchain which I then
>  Hamish> use as external toolchain to build several other boards (all
>  Hamish> armeb-linux-uclibcgnu). So my toolchain lives in the staging
>  Hamish> directory in the same tree.
> 
> So they all put libraries / headers in the same staging_dir? Doesn't

Yes.

> that give problems with packages detecting optional stuff at compile
> time that might not be available for a specific variant (E.G. one
> variant has expat, and another doesn't - Some configure script checks
> for expat and finds it in staging_dir even though it isn't going to be
> there at runtime).

Good point. So far all my boards are very similar so this hasn't been a
problem, but that won't always be the case.

IMHO this is a flaw of the project support - everything should be built
into a project-specific directory. Currently only the kernel and busybox
are built in project_build_$arch.

How would everyone react to a patch which redefines BUILD_DIR to match
PROJECT_BUILD_DIR, ie each project would have
project_build_$arch/$project/staging_dir etc?

I think Ulf commented in the past that he doesn't want to waste the time
spent compiling each package for each board separately, but that seems
to be the only way to do it correctly.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] svncommit: trunk/buildroot/toolchain/external-toolchain

[Ulf Samuelsson]

Hamish Moffatt wrote:
> On Tue, Jun 17, 2008 at 03:45:04PM +0200, Peter Korsgaard wrote:
>>  Hamish> Well I've got one board ("tools", in
>>  Hamish> local/tools/tools.config) to build the toolchain which I
>>  then Hamish> use as external toolchain to build several other
>>  boards (all Hamish> armeb-linux-uclibcgnu). So my toolchain lives
>>  in the staging Hamish> directory in the same tree.
>> 
>> So they all put libraries / headers in the same staging_dir? Doesn't
> 
> Yes.
> 
>> that give problems with packages detecting optional stuff at compile
>> time that might not be available for a specific variant (E.G. one
>> variant has expat, and another doesn't - Some configure script checks
>> for expat and finds it in staging_dir even though it isn't going to
>> be there at runtime).
> 
> Good point. So far all my boards are very similar so this hasn't been
> a problem, but that won't always be the case.
> 
> IMHO this is a flaw of the project support - everything should be
> built into a project-specific directory. Currently only the kernel
> and busybox are built in project_build_$arch.
> 
> How would everyone react to a patch which redefines BUILD_DIR to match
> PROJECT_BUILD_DIR, ie each project would have
> project_build_$arch/$project/staging_dir etc?

No, then you might as well use several buildroot trees.

> 
> I think Ulf commented in the past that he doesn't want to waste the
> time spent compiling each package for each board separately, but that
> seems to be the only way to do it correctly.
> 

You have to be aware of the limitations, that's for sure.
There are a number of packages which can only be built one way
and they can reside in build_<arch>, packages which have different
options needs to be built in project_build_<arch>

> Hamish

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57


Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                 http://www.linux4sam.org/

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 Hamish> How would everyone react to a patch which redefines BUILD_DIR
 Hamish> to match PROJECT_BUILD_DIR, ie each project would have
 Hamish> project_build_$arch/$project/staging_dir etc?

 Hamish> I think Ulf commented in the past that he doesn't want to
 Hamish> waste the time spent compiling each package for each board
 Hamish> separately, but that seems to be the only way to do it
 Hamish> correctly.

Maybe there's a solution in between. Put packages that really can only
be built one way under build_, and all other packages under
project_build, and then have STAGING_DIR under project_build as well
(with some logic to copy/symlink in the toolchain stuff). Then each
variant could use different versions / configurations of the packages,
and we would still only compile the stuff under build_ once (per
version).

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[jacmet at uclibc.org]

Author: jacmet
Date: 2008-10-17 03:19:38 -0700 (Fri, 17 Oct 2008)
New Revision: 23700

Log:
Typo fix in toolchain/external-toolchain/ext-tool.mk

From: Grant Likely <grant.likely@secretlab.ca>

Comment block header documentation typo

Modified:
   trunk/buildroot/toolchain/external-toolchain/ext-tool.mk


Changeset:
Modified: trunk/buildroot/toolchain/external-toolchain/ext-tool.mk
===================================================================
--- trunk/buildroot/toolchain/external-toolchain/ext-tool.mk	2008-10-17 07:52:50 UTC (rev 23699)
+++ trunk/buildroot/toolchain/external-toolchain/ext-tool.mk	2008-10-17 10:19:38 UTC (rev 23700)
@@ -3,7 +3,7 @@
 #
 # $1: source
 # $2: destination
-# $2: strip (y|n)       default is to strip
+# $3: strip (y|n)       default is to strip
 #
 copy_toolchain_lib_root = \
 	LIB="$(strip $1)"; \

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[jacmet at uclibc.org]

Author: jacmet
Date: 2008-11-03 02:32:59 -0800 (Mon, 03 Nov 2008)
New Revision: 23909

Log:
More external toolchain fixes

Fix issues with binary external toolchains

Fix two problems encountered while using an external binary toolchain
generated by crosstool-ng:

 - Don't remove the ending / in LIB_DIR, otherwise find $LIB_DIR
   -maxdepth 1 doesn't find any file in the case LIB_DIR is a symbolic
   link and not a directory.

   For some reason, find -maxdepth 1 doesn't have the same behaviour
   on directories and symbolic links. Demonstration:

   $ mkdir foobar
   $ touch foobar/t1
   $ touch foobar/t2
   $ ln -s foobar barfoo
   $ find foobar -maxdepth 1 -name 't*'
   foobar/t1
   foobar/t2
   $ find barfoo -maxdepth 1 -name 't*'
   $ find barfoo/ -maxdepth 1 -name 't*'
   barfoo/t1
   barfoo/t2

 * Make sure the libraries are writable, otherwise the strip operation
   might fail. The library files may not be writable if the toolchain
   is not writable (which may happen if one wants to prevent anyone
   from overwriting the toolchain, which is done by crosstool-ng, for
   example).

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Modified:
   trunk/buildroot/toolchain/external-toolchain/ext-tool.mk


Changeset:
Modified: trunk/buildroot/toolchain/external-toolchain/ext-tool.mk
===================================================================
--- trunk/buildroot/toolchain/external-toolchain/ext-tool.mk	2008-11-03 10:18:39 UTC (rev 23908)
+++ trunk/buildroot/toolchain/external-toolchain/ext-tool.mk	2008-11-03 10:32:59 UTC (rev 23909)
@@ -10,7 +10,7 @@
 	DST="$(strip $2)"; \
 	STRIP="$(strip $3)"; \
  \
-	LIB_DIR=`$(TARGET_CC) -print-file-name=$${LIB} | sed -e "s,/$${LIB}\$$,,"`; \
+	LIB_DIR=`$(TARGET_CC) -print-file-name=$${LIB} | sed -e "s,$${LIB}\$$,,"`; \
  \
 	if test -z "$${LIB_DIR}"; then \
 		echo "copy_toolchain_lib_root: lib=$${LIB} not found"; \
@@ -27,7 +27,7 @@
 			if test -h $${LIB_DIR}/$${LIB}; then \
 				cp -d $${LIB_DIR}/$${LIB} $(TARGET_DIR)$${DST}/; \
 			elif test -f $${LIB_DIR}/$${LIB}; then \
-				cp $${LIB_DIR}/$${LIB} $(TARGET_DIR)$${DST}/$${LIB}; \
+				$(INSTALL) -D -m0755 $${LIB_DIR}/$${LIB} $(TARGET_DIR)$${DST}/$${LIB}; \
 				case "$${STRIP}" in \
 				(0 | n | no) \
 ;; \

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[jacmet at uclibc.org]

Author: jacmet
Date: 2008-11-03 02:37:27 -0800 (Mon, 03 Nov 2008)
New Revision: 23910

Log:
External toolchain C++ cross-compiler fix

External toolchain C++ cross-compiler fix

package/Makefile.in resets CXX to "" in TARGET_CONFIGURE_OPTS if
BR2_GCC_CROSS_CXX is not set to 'y'. However, when using an external
toolchain, BR2_GCC_CROSS_CXX is not set even if the toolchain has a
C++ cross-compiler.

This patch adds a new BR2_GCC_CROSS_CXX option in the external
toolchain configuration menu, so that just like BR2_INET_RPC,
BR2_INET_IPV6 and the others, it can be set according to the external
toolchain configuration.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Modified:
   trunk/buildroot/toolchain/external-toolchain/Config.in


Changeset:
Modified: trunk/buildroot/toolchain/external-toolchain/Config.in
===================================================================
--- trunk/buildroot/toolchain/external-toolchain/Config.in	2008-11-03 10:32:59 UTC (rev 23909)
+++ trunk/buildroot/toolchain/external-toolchain/Config.in	2008-11-03 10:37:27 UTC (rev 23910)
@@ -93,6 +93,12 @@
 	help
 	  Set this option if the external toolchain supports soft float.
 
+config BR2_GCC_CROSS_CXX
+	bool "Toolchain has C++ cross-compiler ?"
+	help
+	  Set this option if the external toolchain has a C++
+	  cross-compiler.
+
 config BR2_TARGET_OPTIMIZATION
 	string "Target Optimizations"
 	default "-Os -pipe"

[Buildroot] svn commit: trunk/buildroot/toolchain/external-toolchain

[laird at uclibc.org]

Author: laird
Date: 2009-01-12 12:54:30 +0000 (Mon, 12 Jan 2009)
New Revision: 24794

Log:
toolchain/external-toolchain/ext-tool.mk: Support non sysroot-able toolchains

Only copy the sysroot files if the toolchain was built with sysroot support.

Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>



Modified:
   trunk/buildroot/toolchain/external-toolchain/ext-tool.mk


Changeset:
Modified: trunk/buildroot/toolchain/external-toolchain/ext-tool.mk
===================================================================
--- trunk/buildroot/toolchain/external-toolchain/ext-tool.mk	2009-01-12 12:45:48 UTC (rev 24793)
+++ trunk/buildroot/toolchain/external-toolchain/ext-tool.mk	2009-01-12 12:54:30 UTC (rev 24794)
@@ -46,8 +46,8 @@
 
 copy_toolchain_sysroot = \
 	SYSROOT_DIR=`$(TARGET_CC) -v 2>&1 | grep ^Configured | tr " " "\n" | grep -- "--with-sysroot" | cut -f2 -d=`; \
-	cp -a $${SYSROOT_DIR}/* $(STAGING_DIR)/ ; \
-	find $(STAGING_DIR) -type d | xargs chmod 755
+	if [ -n "$${SYSROOT_DIR}" ]; then cp -a $${SYSROOT_DIR}/* $(STAGING_DIR)/ ; \
+	find $(STAGING_DIR) -type d | xargs chmod 755; fi
 
 uclibc: dependencies $(TARGET_DIR)/lib/$(strip $(subst ",, $(BR2_TOOLCHAIN_EXTERNAL_LIB_C)))
 
@@ -59,4 +59,4 @@
 	for libs in $(strip $(subst ",, $(BR2_TOOLCHAIN_EXTERNAL_LIBS))); do \
 		$(call copy_toolchain_lib_root, $$libs, /lib, $(BR2_TOOLCHAIN_EXTERNAL_STRIP)); \
 	done
-	$(call copy_toolchain_sysroot)
\ No newline at end of file
+	$(call copy_toolchain_sysroot)