Summary: * Exercise crosstool-ng and summarize the gaps.
Details: * Exercise crosstool-ng (1) Sync with lp:~linaro-toolchain-dev/crosstool-ng/linaro. (2) Try to config linux-host-baremental-target an mingw32-host-baremental-target. (3) Try to build the toolchain for both embedded toolchain and linaro-gcc-4.6-2011.10 with the config. . C compiler for linux and mingw32 hosts and c++ compiler for linux host can be built without any change. . C++ compiler for mingw32 host can be built after PCH is disabled. . GDB-cross build fail due to dependence packages. * Gaps in crosstool-ng (1) Improve GDB-cross scripts to download and build the dependence packages: expat and ncurses. Or put expat and ncurses as companion_libraries. (2) To remove dependence, embedded toolchain requires more prerequisites like zlib. New config and scripts are required to support the packages. (3) Currently, the embedded toolchain source packages are released as a tarball, which includes gcc, gmp, etc. New scripts are required to support it. (4) To make sure the toolchain can run with lower version glibc like redhat4/5, the embedded toolchain requires lower version native gcc4.3.6 to build it. To support it, . Users can build the native gcc manually, or . Enhance the scripts to add one step to build native gcc. (5) All the default package configurations are different from embedded toolchain internal build scripts. Since the configurations in embedded toolchain had been tuned and tested, we will change the configurations in crosstool-ng if they do not match and not configurable. The same rule will apply for linaro toolchain.
Plans: * Write scripts to re-pack the embedded toolchain source packages. * Add the supports for all prerequisites in crosstool-ng menuconfig.
Thanks! -Zhenqiang
You may find the extensions at https://github.com/mkedwards/crosstool-ng useful.
Cheers, - Michael
On Sun, Oct 23, 2011 at 6:09 PM, Zhenqiang Chen zhenqiang.chen@linaro.org wrote:
Summary:
- Exercise crosstool-ng and summarize the gaps.
Details:
- Exercise crosstool-ng
(1) Sync with lp:~linaro-toolchain-dev/crosstool-ng/linaro. (2) Try to config linux-host-baremental-target an mingw32-host-baremental-target. (3) Try to build the toolchain for both embedded toolchain and linaro-gcc-4.6-2011.10 with the config. . C compiler for linux and mingw32 hosts and c++ compiler for linux host can be built without any change. . C++ compiler for mingw32 host can be built after PCH is disabled. . GDB-cross build fail due to dependence packages.
- Gaps in crosstool-ng
(1) Improve GDB-cross scripts to download and build the dependence packages: expat and ncurses. Or put expat and ncurses as companion_libraries. (2) To remove dependence, embedded toolchain requires more prerequisites like zlib. New config and scripts are required to support the packages. (3) Currently, the embedded toolchain source packages are released as a tarball, which includes gcc, gmp, etc. New scripts are required to support it. (4) To make sure the toolchain can run with lower version glibc like redhat4/5, the embedded toolchain requires lower version native gcc4.3.6 to build it. To support it, . Users can build the native gcc manually, or . Enhance the scripts to add one step to build native gcc. (5) All the default package configurations are different from embedded toolchain internal build scripts. Since the configurations in embedded toolchain had been tuned and tested, we will change the configurations in crosstool-ng if they do not match and not configurable. The same rule will apply for linaro toolchain.
Plans:
- Write scripts to re-pack the embedded toolchain source packages.
- Add the supports for all prerequisites in crosstool-ng menuconfig.
Thanks! -Zhenqiang
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Mon, Oct 24, 2011 at 2:09 PM, Zhenqiang Chen zhenqiang.chen@linaro.org wrote:
Summary:
- Exercise crosstool-ng and summarize the gaps.
Details:
- Exercise crosstool-ng
(1) Sync with lp:~linaro-toolchain-dev/crosstool-ng/linaro. (2) Try to config linux-host-baremental-target an mingw32-host-baremental-target. (3) Try to build the toolchain for both embedded toolchain and linaro-gcc-4.6-2011.10 with the config. . C compiler for linux and mingw32 hosts and c++ compiler for linux host can be built without any change. . C++ compiler for mingw32 host can be built after PCH is disabled.
Yip, I saw that too.
. GDB-cross build fail due to dependence packages.
- Gaps in crosstool-ng
(1) Improve GDB-cross scripts to download and build the dependence packages: expat and ncurses. Or put expat and ncurses as companion_libraries.
mkedwards has these scripted up at: https://github.com/mkedwards/crosstool-ng/tree/master/scripts/build/companio...
We should add these in upstream. I'd rather focus on GCC first, get that out as a prototype, then add GDB.
(2) To remove dependence, embedded toolchain requires more prerequisites like zlib. New config and scripts are required to support the packages.
GCC and similar ship with a copy of zlib. I wonder if we should use that?
(3) Currently, the embedded toolchain source packages are released as a tarball, which includes gcc, gmp, etc. New scripts are required to support it.
We should check what needs to be done to meet the licenses. All of the tarballs used in building the binary are in .build/taraballs.
(4) To make sure the toolchain can run with lower version glibc like redhat4/5, the embedded toolchain requires lower version native gcc4.3.6 to build it.
Why is this? The RHEL 5 GCC 4.1 builds the glibc compiler just fine.
To support it, . Users can build the native gcc manually, or . Enhance the scripts to add one step to build native gcc. (5) All the default package configurations are different from embedded toolchain internal build scripts. Since the configurations in embedded toolchain had been tuned and tested, we will change the configurations in crosstool-ng if they do not match and not configurable. The same rule will apply for linaro toolchain.
Yip. We should make them configurable and get that upstream.
-- Michael
mkedwards has these scripted up at: https://github.com/mkedwards/crosstool-ng/tree/master/scripts/build/companio...
We should add these in upstream. I'd rather focus on GCC first, get that out as a prototype, then add GDB.
I tried tried mkedwards's extention. The GDB-cross can build.
GCC and similar ship with a copy of zlib. I wonder if we should use that?
zlib is used to build binutils, which is built before GCC.
If you install a 32-bit binary toolchain on 64-bit system, you might have link error. By default, there is no 32-bit zlib on 64-bit system. You have to install 32-bit zlib manually.
(3) Currently, the embedded toolchain source packages are released as a tarball, which includes gcc, gmp, etc. New scripts are required to support it.
We should check what needs to be done to meet the licenses. All of the tarballs used in building the binary are in .build/taraballs.
I will add scripts to copy the tarballs to .build/tarballs.
(4) To make sure the toolchain can run with lower version glibc like redhat4/5, the embedded toolchain requires lower version native gcc4.3.6 to build it.
Why is this? The RHEL 5 GCC 4.1 builds the glibc compiler just fine.
There is no problem if users build and run the toolchain on the same platform.
We expect users can install and use the binary toolchain on systems without rebuilding it. E.g. If we build toolchain on Ubuntu 10.4, can users use it on RHEL4?
In fact, users had reported bugs about this issue.
The official release of embedded toolchain is built by gcc-4.3.6 on Ubuntu-8.10.
Thanks! -Zhenqiang
On Tue, Oct 25, 2011 at 4:27 PM, Zhenqiang Chen zhenqiang.chen@linaro.org wrote:
mkedwards has these scripted up at: https://github.com/mkedwards/crosstool-ng/tree/master/scripts/build/companio...
We should add these in upstream. I'd rather focus on GCC first, get that out as a prototype, then add GDB.
I tried tried mkedwards's extention. The GDB-cross can build.
GCC and similar ship with a copy of zlib. I wonder if we should use that?
zlib is used to build binutils, which is built before GCC. If you install a 32-bit binary toolchain on 64-bit system, you might have link error. By default, there is no 32-bit zlib on 64-bit system. You have to install 32-bit zlib manually.
Yip, but both binutils and GCC include a local copy of the zlib source that can be statically linked in during the build. It might be easier than doing it separetly, especially as zlib is messy to build.
(3) Currently, the embedded toolchain source packages are released as a tarball, which includes gcc, gmp, etc. New scripts are required to support it.
We should check what needs to be done to meet the licenses. All of the tarballs used in building the binary are in .build/taraballs.
I will add scripts to copy the tarballs to .build/tarballs.
From I guess?
(4) To make sure the toolchain can run with lower version glibc like redhat4/5, the embedded toolchain requires lower version native gcc4.3.6 to build it.
Why is this? The RHEL 5 GCC 4.1 builds the glibc compiler just fine.
There is no problem if users build and run the toolchain on the same platform.
We expect users can install and use the binary toolchain on systems without rebuilding it. E.g. If we build toolchain on Ubuntu 10.4, can users use it on RHEL4?
The glibc is more of a concern than the compiler. RHEL 5 is the earliest version we need to support which is GLIBC 2.5 based. Ubuntu 8.10 uses GLIBC 2.8 and might turn on other features like hardening or the stack protector which could cause trouble.
I think we should build and test the binary under RHEL 5 itself.
-- Michael
zlib is used to build binutils, which is built before GCC. If you install a 32-bit binary toolchain on 64-bit system, you might have link error. By default, there is no 32-bit zlib on 64-bit system. You have to install 32-bit zlib manually.
Yip, but both binutils and GCC include a local copy of the zlib source that can be statically linked in during the build. It might be easier than doing it separetly, especially as zlib is messy to build.
Are you sure? I check binutils-2.21 source code. There is no zlib related source code like zlib.h. If it has, we should not build zlib separately.
(3) Currently, the embedded toolchain source packages are released as a tarball, which includes gcc, gmp, etc. New scripts are required to support it.
We should check what needs to be done to meet the licenses. All of the tarballs used in building the binary are in .build/taraballs.
I will add scripts to copy the tarballs to .build/tarballs.
From I guess?
The root cause for this gap is that current embedded toolchain release creates some source packages from internal git server. And the package name is not in standard format: NAME-VERSION.
The script will be a workaround to build and test the embedded toolchain.
I will work with local team to improve the build process for future release. All the source packages should get from public links with standard format.
The glibc is more of a concern than the compiler. RHEL 5 is the earliest version we need to support which is GLIBC 2.5 based. Ubuntu 8.10 uses GLIBC 2.8 and might turn on other features like hardening or the stack protector which could cause trouble.
I think we should build and test the binary under RHEL 5 itself.
Stack protector is the issue on RHEL5. For us, we should build and test the binary under RHEL5.
What do we release: series of toolchains for different versions of Linux or just one which can run on most popular linux versions? If we only release one binary, what's the preferred build system? And we should make sure it can run on different linux systems.
Thanks! -Zhenqiang
On Thu, Oct 27, 2011 at 5:18 PM, Zhenqiang Chen zhenqiang.chen@linaro.org wrote:
zlib is used to build binutils, which is built before GCC. If you install a 32-bit binary toolchain on 64-bit system, you might have link error. By default, there is no 32-bit zlib on 64-bit system. You have to install 32-bit zlib manually.
Yip, but both binutils and GCC include a local copy of the zlib source that can be statically linked in during the build. It might be easier than doing it separetly, especially as zlib is messy to build.
Are you sure? I check binutils-2.21 source code. There is no zlib related source code like zlib.h. If it has, we should not build zlib separately.
Sorry, I was wrong. sourceware src/ has zlib. gcc pulls that in but binutils doesn't.
(3) Currently, the embedded toolchain source packages are released as a tarball, which includes gcc, gmp, etc. New scripts are required to support it.
We should check what needs to be done to meet the licenses. All of the tarballs used in building the binary are in .build/taraballs.
I will add scripts to copy the tarballs to .build/tarballs.
From I guess?
The root cause for this gap is that current embedded toolchain release creates some source packages from internal git server. And the package name is not in standard format: NAME-VERSION.
The script will be a workaround to build and test the embedded toolchain.
I will work with local team to improve the build process for future release. All the source packages should get from public links with standard format.
The glibc is more of a concern than the compiler. RHEL 5 is the earliest version we need to support which is GLIBC 2.5 based. Ubuntu 8.10 uses GLIBC 2.8 and might turn on other features like hardening or the stack protector which could cause trouble.
I think we should build and test the binary under RHEL 5 itself.
Stack protector is the issue on RHEL5. For us, we should build and test the binary under RHEL5.
Agreed.
What do we release: series of toolchains for different versions of Linux or just one which can run on most popular linux versions? If we only release one binary, what's the preferred build system? And we should make sure it can run on different linux systems.
In the requirements spec I said we should support the following:
Redhat Enterprise Linux 5.7 Ubuntu 10.04.3 and 11.05 Fedora 15 Debian 6.0.2 openSUSE 11.4
If we build on the oldest (RHEL 5) then it should work on the more recent versions. We'll need to test on all of these for the first release, but should be able to just test on RHEL and, say, Ubuntu 11.05 for subsequent versions.
The cloud and virtualisation does make this easier.
-- Michael
linaro-toolchain@lists.linaro.org
-
Michael Hope -
Michael K. Edwards -
Zhenqiang Chen