[Buildroot] Binary toolchain fails

[Buildroot] Binary toolchain fails

[Ulf Samuelsson]

I am testing the binary toolchain, with a toolchain built
by another buildroot project.

Several packages does not build correctly.

"-lintl" and "-liconv are" not found.

Examples are "e2fsprogs" and "libgpg-error"

by doing


ifeq	($(BR2_PACKAGE_LIBICONV),y)
LIBGPG_ERROR_CONF_OPT += --with-libiconv-prefix=$(STAGING_DIR)/usr
endif

ifeq	($(BR2_PACKAGE_LIBINTL),y)
LIBGPG_ERROR_CONF_OPT += --with-libintl-prefix=$(STAGING_DIR)/usr
endif

...

$(LIBGPG_ERROR_DIR)/.configured: $(LIBGPG_ERROR_DIR)/.source
	(cd $(LIBGPG_ERROR_DIR); rm -f config.cache; \
...
		./configure \
...
		$(LIBGPG_ERROR_CONF_OPT) \
...
	)

and adding CFLAGS to the make, (moved from configure)

$(LIBGPG_ERROR_DIR)/.configured
	CFLAGS="$(TARGET_CFLAGS)" \
	$(MAKE) CC=$(TARGET_CC) -C $(LIBGPG_ERROR_DIR)

Both packages builds with this fix, 
but since it is systematic the change should probably be made elsewhere.
(package/Makefile.in?)

Any drawbacks with this change?


At least one of the following is screwed up when 
you use an binary toolchain generated by buildroot.
$(TARGET_CONFIGURE_OPTS)
$(TARGET_CONFIGURE_ARGS)
?CFLAGS="$(TARGET_CFLAGS)"

KERNEL HEADERS
--------------
If you build just the toolchain to, lets say, /usr/local/arm/gcc-4.3.2, 
and use this directory as GCCROOT in your external toolchain,
you have no kernel-headers.

Should the kernel headers really be installed in
toolchain_build_ARCH/linux?
Why not in "$(STAGING_DIR)/usr/include/linux" ?

If you are not building a toolchain from source, then
the kernel-headers target is not available.
I moved them out from the if BUILDROOT_TOOLCHAIN_SOURCE
clause so they build for me, but I think that
is the wrong solution and generating the headers in 
?"$(STAGING_DIR)/usr/include/linux" is better.

Comments?



BR
Ulf Samuelsson

[Buildroot] Binary toolchain fails

[Ulf Samuelsson]

s?n 2009-02-01 klockan 11:34 +0100 skrev Ulf Samuelsson:
> I am testing the binary toolchain, with a toolchain built
> by another buildroot project.
> 
> Several packages does not build correctly.
> 
> "-lintl" and "-liconv are" not found.
> 
> Examples are "e2fsprogs" and "libgpg-error"
> 
> by doing
> 
> 
> ifeq	($(BR2_PACKAGE_LIBICONV),y)
> LIBGPG_ERROR_CONF_OPT += --with-libiconv-prefix=$(STAGING_DIR)/usr
> endif
> 
> ifeq	($(BR2_PACKAGE_LIBINTL),y)
> LIBGPG_ERROR_CONF_OPT += --with-libintl-prefix=$(STAGING_DIR)/usr
> endif
> 
> ...
> 
> $(LIBGPG_ERROR_DIR)/.configured: $(LIBGPG_ERROR_DIR)/.source
> 	(cd $(LIBGPG_ERROR_DIR); rm -f config.cache; \
> ...
> 		./configure \
> ...
> 		$(LIBGPG_ERROR_CONF_OPT) \
> ...
> 	)
> 
> and adding CFLAGS to the make, (moved from configure)
> 
> $(LIBGPG_ERROR_DIR)/.configured
> 	CFLAGS="$(TARGET_CFLAGS)" \
> 	$(MAKE) CC=$(TARGET_CC) -C $(LIBGPG_ERROR_DIR)
> 
> Both packages builds with this fix, 
> but since it is systematic the change should probably be made elsewhere.
> (package/Makefile.in?)
> 
> Any drawbacks with this change?
> 
> 
> At least one of the following is screwed up when 
> you use an binary toolchain generated by buildroot.
> $(TARGET_CONFIGURE_OPTS)
> $(TARGET_CONFIGURE_ARGS)
> ?CFLAGS="$(TARGET_CFLAGS)"
> 
> KERNEL HEADERS
> --------------
> If you build just the toolchain to, lets say, /usr/local/arm/gcc-4.3.2, 
> and use this directory as GCCROOT in your external toolchain,
> you have no kernel-headers.
> 
> Should the kernel headers really be installed in
> toolchain_build_ARCH/linux?
> Why not in "$(STAGING_DIR)/usr/include/linux" ?
> 
> If you are not building a toolchain from source, then
> the kernel-headers target is not available.
> I moved them out from the if BUILDROOT_TOOLCHAIN_SOURCE
> clause so they build for me, but I think that
> is the wrong solution and generating the headers in 
> ?"$(STAGING_DIR)/usr/include/linux" is better.
> 
> Comments?

There are multiple changes needed for this to work.

Most compile switches are not set if you use a binary toolchain.
This includes sysroot.

You have a setting, ?BR2_TARGET_OPTIMIZATION, but this
seems to be ignored for two reasons,
1) ?TARGET_OPTIMIZATION is set in gcc-*.mk which is ignored
2) package/Makefile.in is again setting ??TARGET_OPTIMIZATION
   I.E ??TARGET_OPTIMIZATION= instead of ??TARGET_OPTIMIZATION+=

Once that is fixed, sysroot is still not enabled 
since the configuration variables for sysroot are disabled
when you use a binary toolchain.

BR2_TARGET_OPTIMIZATION="-Os -pipe --sysroot=$(STAGING_DIR)/ -isysroot
$(STAGING_DIR)"

Would let me build packages with problems.

Since there are so many changes needed to get binary toolchains
to work, I propose we simply disable them in the distribution
and fix the problem afterwards.

BR
Ulf Samuelsson

> 
> 
> 
> BR
> Ulf Samuelsson
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Binary toolchain fails

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Ulf> Once that is fixed, sysroot is still not enabled 
 Ulf> since the configuration variables for sysroot are disabled
 Ulf> when you use a binary toolchain.

 Ulf> BR2_TARGET_OPTIMIZATION="-Os -pipe --sysroot=$(STAGING_DIR)/ -isysroot
 Ulf> $(STAGING_DIR)"

Don't forget the !SYSROOT case.

 Ulf> Would let me build packages with problems.

 Ulf> Since there are so many changes needed to get binary toolchains
 Ulf> to work, I propose we simply disable them in the distribution
 Ulf> and fix the problem afterwards.

I wouldn't do that as we pretty frequently hear from people apparently
using it (Like Daniel's latest changes), so it obviously works for
some.

-- 
Bye, Peter Korsgaard

[Buildroot] Binary toolchain fails

[Ulf Samuelsson]

s?n 2009-02-01 klockan 14:08 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  Ulf> Once that is fixed, sysroot is still not enabled 
>  Ulf> since the configuration variables for sysroot are disabled
>  Ulf> when you use a binary toolchain.
> 
>  Ulf> BR2_TARGET_OPTIMIZATION="-Os -pipe --sysroot=$(STAGING_DIR)/ -isysroot
>  Ulf> $(STAGING_DIR)"
> 
?
> Don't forget the !SYSROOT case.
> 

?BR2_TARGET_OPTIMIZATION is a user definable thing
in the .config file.
Anyone not having sysroot would have to change these parameters.

Since basically nothing is set for a binary toolchain,
this variable would 
have to contain a lot...

Better probably to have an include file describing the toolchain
functionality, which gets included after the .config.

>  Ulf> Would let me build packages with problems.
> 
>  Ulf> Since there are so many changes needed to get binary toolchains
>  Ulf> to work, I propose we simply disable them in the distribution
>  Ulf> and fix the problem afterwards.
> 
> I wouldn't do that as we pretty frequently hear from people apparently
> using it (Like Daniel's latest changes), so it obviously works for
> some.
> 

BR
Ulf Samuelsson

[Buildroot] Binary toolchain fails

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Ulf> I am testing the binary toolchain, with a toolchain built
 Ulf> by another buildroot project.

The external toolchain stuff? That's afaik known to not work.

 Ulf> Several packages does not build correctly.

 Ulf> "-lintl" and "-liconv are" not found.

Strange, so the packages don't respect CFLAGS / LDFLAGS?

 Ulf> Examples are "e2fsprogs" and "libgpg-error"

 Ulf> by doing


 Ulf> ifeq	($(BR2_PACKAGE_LIBICONV),y)
 Ulf> LIBGPG_ERROR_CONF_OPT += --with-libiconv-prefix=$(STAGING_DIR)/usr
 Ulf> endif

 Ulf> ifeq	($(BR2_PACKAGE_LIBINTL),y)
 Ulf> LIBGPG_ERROR_CONF_OPT += --with-libintl-prefix=$(STAGING_DIR)/usr
 Ulf> endif

And what about the 10s of other libraries we have? To me it seems like
something else is broken in the external toolchain stuff, and this is
just pampering over it.

 Ulf> KERNEL HEADERS
 Ulf> --------------
 Ulf> If you build just the toolchain to, lets say, /usr/local/arm/gcc-4.3.2, 
 Ulf> and use this directory as GCCROOT in your external toolchain,
 Ulf> you have no kernel-headers.

 Ulf> Should the kernel headers really be installed in
 Ulf> toolchain_build_ARCH/linux?
 Ulf> Why not in "$(STAGING_DIR)/usr/include/linux" ?

 Ulf> If you are not building a toolchain from source, then
 Ulf> the kernel-headers target is not available.
 Ulf> I moved them out from the if BUILDROOT_TOOLCHAIN_SOURCE
 Ulf> clause so they build for me, but I think that
 Ulf> is the wrong solution and generating the headers in 
 Ulf> ?"$(STAGING_DIR)/usr/include/linux" is better.

 Ulf> Comments?

The kernel headers are pretty closely related to the C library, and
hence the toolchain, so my initial thought is that it sounds wrong.
But if you want to work on making the external toolchain stuff less
broken AFTER the release, then that's fine as long as it doesn't add
too much complications and the internal toolchain stuff keeps working.

-- 
Bye, Peter Korsgaard

[Buildroot] Binary toolchain fails

[Ulf Samuelsson]

s?n 2009-02-01 klockan 14:06 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  Ulf> I am testing the binary toolchain, with a toolchain built
>  Ulf> by another buildroot project.
> 
> The external toolchain stuff? That's afaik known to not work.
> 
>  Ulf> Several packages does not build correctly.
> 
>  Ulf> "-lintl" and "-liconv are" not found.
> 
> Strange, so the packages don't respect CFLAGS / LDFLAGS?
> 
>  Ulf> Examples are "e2fsprogs" and "libgpg-error"
> 
>  Ulf> by doing
> 
> 
>  Ulf> ifeq	($(BR2_PACKAGE_LIBICONV),y)
>  Ulf> LIBGPG_ERROR_CONF_OPT += --with-libiconv-prefix=$(STAGING_DIR)/usr
>  Ulf> endif
> 
>  Ulf> ifeq	($(BR2_PACKAGE_LIBINTL),y)
>  Ulf> LIBGPG_ERROR_CONF_OPT += --with-libintl-prefix=$(STAGING_DIR)/usr
>  Ulf> endif
> 
> And what about the 10s of other libraries we have? To me it seems like
> something else is broken in the external toolchain stuff, and this is
> just pampering over it.
> 
>  Ulf> KERNEL HEADERS
>  Ulf> --------------
>  Ulf> If you build just the toolchain to, lets say, /usr/local/arm/gcc-4.3.2, 
>  Ulf> and use this directory as GCCROOT in your external toolchain,
>  Ulf> you have no kernel-headers.
> 
>  Ulf> Should the kernel headers really be installed in
>  Ulf> toolchain_build_ARCH/linux?
>  Ulf> Why not in "$(STAGING_DIR)/usr/include/linux" ?
> 
>  Ulf> If you are not building a toolchain from source, then
>  Ulf> the kernel-headers target is not available.
>  Ulf> I moved them out from the if BUILDROOT_TOOLCHAIN_SOURCE
>  Ulf> clause so they build for me, but I think that
>  Ulf> is the wrong solution and generating the headers in 
>  Ulf> ?"$(STAGING_DIR)/usr/include/linux" is better.
> 
>  Ulf> Comments?
> 
> The kernel headers are pretty closely related to the C library, and
> hence the toolchain, so my initial thought is that it sounds wrong.


I think the kernel headers should be in $(STAGING_DIR)/usr/include/linux
You think this is wrong?

THe other thing is just a workadound!

BR
Ulf Samuelsson

> But if you want to work on making the external toolchain stuff less
> broken AFTER the release, then that's fine as long as it doesn't add
> too much complications and the internal toolchain stuff keeps working.
> 
> -- 
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] Binary toolchain fails

[Daniel Laird]

Regarding the external toolchain stuff.

I am using a toolchain built by a different vendor and buildroot with no major issues.
I do use the ext-tool.mk version and for that I make sure that the sysroot of my compiler is copied into $(STAGING_DIR).  
The slight issue I have is that my toolchain vendor has a cross directory and a rootfs directory.  
The toolchain reports its sysroot as /path/to/cross.  
So the exttool.mk tries to copy that into STAGINGDIR.  However the files in cross are not the correct files.  

It should be using the files in rootfs.  So I have extended ext-tool.mk to allow the directory that gets copied over at the start of the process to be overridden (supplied) or guessed (--sysroot option). (will look to add this after release)

This gets copied into $(STAGINGDIR) and then I pass --sysroot=$(STAGING_DIR) to the compiler.

This is working rather well.
The stuff that seems broken (according to email traffic) is the toolchain+source option so buildroot built toolchain appears to work well and I am finding the ext-tool.mk binary toolchain works well.

Cheers
Dan

-----Original Message-----
From: buildroot-bounces@busybox.net [mailto:buildroot-bounces at busybox.net] On Behalf Of Ulf Samuelsson
Sent: 2009 Feb 01 14:01
To: Peter Korsgaard
Cc: buildroot at uclibc.org
Subject: Re: [Buildroot] Binary toolchain fails

s?n 2009-02-01 klockan 14:06 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
>  Ulf> I am testing the binary toolchain, with a toolchain built
>  Ulf> by another buildroot project.
> 
> The external toolchain stuff? That's afaik known to not work.
> 
>  Ulf> Several packages does not build correctly.
> 
>  Ulf> "-lintl" and "-liconv are" not found.
> 
> Strange, so the packages don't respect CFLAGS / LDFLAGS?
> 
>  Ulf> Examples are "e2fsprogs" and "libgpg-error"
> 
>  Ulf> by doing
> 
> 
>  Ulf> ifeq	($(BR2_PACKAGE_LIBICONV),y)
>  Ulf> LIBGPG_ERROR_CONF_OPT += --with-libiconv-prefix=$(STAGING_DIR)/usr
>  Ulf> endif
> 
>  Ulf> ifeq	($(BR2_PACKAGE_LIBINTL),y)
>  Ulf> LIBGPG_ERROR_CONF_OPT += --with-libintl-prefix=$(STAGING_DIR)/usr
>  Ulf> endif
> 
> And what about the 10s of other libraries we have? To me it seems like
> something else is broken in the external toolchain stuff, and this is
> just pampering over it.
> 
>  Ulf> KERNEL HEADERS
>  Ulf> --------------
>  Ulf> If you build just the toolchain to, lets say, /usr/local/arm/gcc-4.3.2, 
>  Ulf> and use this directory as GCCROOT in your external toolchain,
>  Ulf> you have no kernel-headers.
> 
>  Ulf> Should the kernel headers really be installed in
>  Ulf> toolchain_build_ARCH/linux?
>  Ulf> Why not in "$(STAGING_DIR)/usr/include/linux" ?
> 
>  Ulf> If you are not building a toolchain from source, then
>  Ulf> the kernel-headers target is not available.
>  Ulf> I moved them out from the if BUILDROOT_TOOLCHAIN_SOURCE
>  Ulf> clause so they build for me, but I think that
>  Ulf> is the wrong solution and generating the headers in 
>  Ulf> ?"$(STAGING_DIR)/usr/include/linux" is better.
> 
>  Ulf> Comments?
> 
> The kernel headers are pretty closely related to the C library, and
> hence the toolchain, so my initial thought is that it sounds wrong.


I think the kernel headers should be in $(STAGING_DIR)/usr/include/linux
You think this is wrong?

THe other thing is just a workadound!

BR
Ulf Samuelsson

> But if you want to work on making the external toolchain stuff less
> broken AFTER the release, then that's fine as long as it doesn't add
> too much complications and the internal toolchain stuff keeps working.
> 
> -- 
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot