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

[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 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

[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>