| Message ID | edadd06cb17fd3a45501.1322438247@crucis |
|---|---|
| State | New |
| Headers | show |
> comment "Host system" > diff -r 49af7802dcd5 -r edadd06cb17f scripts/crosstool-NG.sh.in > --- a/scripts/crosstool-NG.sh.in Tue Nov 22 10:08:10 2011 +0100 > +++ b/scripts/crosstool-NG.sh.in Mon Nov 28 12:56:25 2011 +1300 > @@ -390,6 +390,13 @@ > fi > > for tool in ar as dlltool gcc g++ gcj gnatbind gnatmake ld nm objcopy objdump ranlib strip windres; do > + # Re-map GCC and G++ to the corresponding LSB names > + case "${CT_BUILD_USE_LSBCC},${m},${tool}" in > + y,BUILD,gcc) target="lsbcc";; > + y,BUILD,g++) target="lsbc++";; Which should read HOST, not BUILD... -- Michael
Michael, All, On Monday 28 November 2011 00:57:27 Michael Hope wrote: > # HG changeset patch > # User Michael Hope <michael.hope@linaro.org> > # Date 1322438185 -46800 > # Branch lsb > # Node ID edadd06cb17fd3a45501afe22ae39a76f4a76fa2 > # Parent 49af7802dcd538ec3cb64337030b03ac2c6344d2 > scripts: support building with the LSB wrappers > > If set, look for 'lsbcc' instead of 'gcc' and 'lsbc++ instead of g++ > and use them when building. > > The Linux Standard Base defines a set of libraries and APIs that are > implemented by most distros. If you build against these APIs then in > theory the program can run on any LSB distro instead of just the > host. > > LSB provide a compiler wrapper for the host C and C++ compilers called > 'lsbcc' and 'lsbc++'. The wrapper checks the executable name to figure > out if you're calling the C or C++ compiler so you have to call these > names exactly. > > Caveats: You need a 4.1 or 4.2 compiler to build. Various parts of > the toolchain don't compile LSB 3.0+ header files. Some parts > accidentally use the host include files. A patch that works around > these is at: > http://people.linaro.org/~michaelh/keep/00-crosstool-lsb-hacks.patch > > Nits: I'm abusing the case statement to do an AND but it makes the > default value cleaner. > > Signed-off-by: Michael Hope <michael.hope@linaro.org> > > diff -r 49af7802dcd5 -r edadd06cb17f config/toolchain.in > --- a/config/toolchain.in Tue Nov 22 10:08:10 2011 +0100 > +++ b/config/toolchain.in Mon Nov 28 12:56:25 2011 +1300 > @@ -247,6 +247,18 @@ > for that by checking the tools without the suffix in case it can > not find some of the tool. > > +config BUILD_USE_LSBCC > + bool > + prompt "| Build using the Linux Standard Base compilers" > + help > + Set to use the LSB C and C++ compiler wrappers lsbcc and > + lsbc++ instead of gcc and g++. > + > + LSB applications are more portable and should run on any LSB > + compliant Linux based operating system. Note that building > + against a LSB 3.0 system may require a pre-4.3 version of GCC That sounds like a test should be made at runtime to check that the available gcc is the correct version. > + and local patches to the LSB build tree. And this sounds like a show-stopper. This would require that the user does patch his/her system, and that's definitely not something we want to impose on him/her. :-( > if CANADIAN > > comment "Host system" > diff -r 49af7802dcd5 -r edadd06cb17f scripts/crosstool-NG.sh.in > --- a/scripts/crosstool-NG.sh.in Tue Nov 22 10:08:10 2011 +0100 > +++ b/scripts/crosstool-NG.sh.in Mon Nov 28 12:56:25 2011 +1300 > @@ -390,6 +390,13 @@ > fi > > for tool in ar as dlltool gcc g++ gcj gnatbind gnatmake ld nm objcopy objdump ranlib strip windres; do > + # Re-map GCC and G++ to the corresponding LSB names > + case "${CT_BUILD_USE_LSBCC},${m},${tool}" in > + y,BUILD,gcc) target="lsbcc";; > + y,BUILD,g++) target="lsbc++";; > + *) target="${tool}";; > + esac (OK, I saw your second mail about s/BUILD/HOST/) I don't like the 'target' variable name. Why don't you overload the existing variable 'tool'? > # First try with prefix + suffix > # Then try with prefix only > # Then try with suffix only, but only for BUILD, and HOST iff REAL_BUILD == REAL_HOST > @@ -397,17 +404,17 @@ > # This is needed, because some tools have a prefix and > # a suffix (eg. gcc), while others may have only one, > # or even none (eg. binutils) > - where=$(CT_Which "${t}${tool}${!s}") > - [ -z "${where}" ] && where=$(CT_Which "${t}${tool}") > + where=$(CT_Which "${t}${target}${!s}") > + [ -z "${where}" ] && where=$(CT_Which "${t}${target}") > if [ -z "${where}" \ > -a \( "${m}" = "BUILD" \ > -o "${CT_REAL_BUILD}" = "${!r}" \) ]; then > - where=$(CT_Which "${tool}${!s}") > + where=$(CT_Which "${target}${!s}") > fi > if [ -z "${where}" \ > -a \( "${m}" = "BUILD" \ > -o "${CT_REAL_BUILD}" = "${!r}" \) ]; then > - where=$(CT_Which "${tool}") > + where=$(CT_Which "${target}") > fi > > # Not all tools are available for all platforms, but some are really, Otherwise, nothing to say. I'll have to look here how it behaves before I can comment more. Thank you! Regards, Yann E. MORIN.
On Tue, Nov 29, 2011 at 7:33 AM, Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote: > Michael, All, > > On Monday 28 November 2011 00:57:27 Michael Hope wrote: >> # HG changeset patch >> # User Michael Hope <michael.hope@linaro.org> >> # Date 1322438185 -46800 >> # Branch lsb >> # Node ID edadd06cb17fd3a45501afe22ae39a76f4a76fa2 >> # Parent 49af7802dcd538ec3cb64337030b03ac2c6344d2 >> scripts: support building with the LSB wrappers >> >> If set, look for 'lsbcc' instead of 'gcc' and 'lsbc++ instead of g++ >> and use them when building. >> >> The Linux Standard Base defines a set of libraries and APIs that are >> implemented by most distros. If you build against these APIs then in >> theory the program can run on any LSB distro instead of just the >> host. >> >> LSB provide a compiler wrapper for the host C and C++ compilers called >> 'lsbcc' and 'lsbc++'. The wrapper checks the executable name to figure >> out if you're calling the C or C++ compiler so you have to call these >> names exactly. >> >> Caveats: You need a 4.1 or 4.2 compiler to build. Various parts of >> the toolchain don't compile LSB 3.0+ header files. Some parts >> accidentally use the host include files. A patch that works around >> these is at: >> http://people.linaro.org/~michaelh/keep/00-crosstool-lsb-hacks.patch >> >> Nits: I'm abusing the case statement to do an AND but it makes the >> default value cleaner. >> >> Signed-off-by: Michael Hope <michael.hope@linaro.org> >> >> diff -r 49af7802dcd5 -r edadd06cb17f config/toolchain.in >> --- a/config/toolchain.in Tue Nov 22 10:08:10 2011 +0100 >> +++ b/config/toolchain.in Mon Nov 28 12:56:25 2011 +1300 >> @@ -247,6 +247,18 @@ >> for that by checking the tools without the suffix in case it can >> not find some of the tool. >> >> +config BUILD_USE_LSBCC >> + bool >> + prompt "| Build using the Linux Standard Base compilers" >> + help >> + Set to use the LSB C and C++ compiler wrappers lsbcc and >> + lsbc++ instead of gcc and g++. >> + >> + LSB applications are more portable and should run on any LSB >> + compliant Linux based operating system. Note that building >> + against a LSB 3.0 system may require a pre-4.3 version of GCC > > That sounds like a test should be made at runtime to check that the > available gcc is the correct version. Not sure on this. The LSB 3.0 C++ headers don't work with G++ 4.3 or later due to the __is_pod() builtin. There's no reason this couldn't be fixed in LSB 4.0 or later versions. C only code is unaffected so if you drop Graphite and GOLD then you're fine. >> + and local patches to the LSB build tree. > > And this sounds like a show-stopper. This would require that the user does > patch his/her system, and that's definitely not something we want to > impose on him/her. :-( Yeah, it's a bit of a mess. There's things like: * /usr/include is still in the include path so non-LSB headers get picked up * ctypes.h has trailing commas on the final enum value and g++ 4.1 doesn't like that * strings.h has a bzero() which is a builtin or macro somewhere else All of these are build environment changes and don't affect the LSB compatibility at least... >> if CANADIAN >> >> comment "Host system" >> diff -r 49af7802dcd5 -r edadd06cb17f scripts/crosstool-NG.sh.in >> --- a/scripts/crosstool-NG.sh.in Tue Nov 22 10:08:10 2011 +0100 >> +++ b/scripts/crosstool-NG.sh.in Mon Nov 28 12:56:25 2011 +1300 >> @@ -390,6 +390,13 @@ >> fi >> >> for tool in ar as dlltool gcc g++ gcj gnatbind gnatmake ld nm objcopy objdump ranlib strip windres; do >> + # Re-map GCC and G++ to the corresponding LSB names >> + case "${CT_BUILD_USE_LSBCC},${m},${tool}" in >> + y,BUILD,gcc) target="lsbcc";; >> + y,BUILD,g++) target="lsbc++";; >> + *) target="${tool}";; >> + esac > > (OK, I saw your second mail about s/BUILD/HOST/) > I don't like the 'target' variable name. Why don't you overload the existing > variable 'tool'? 'tool' is used in the final stub name such as x86_64-foo-linux-gcc. >> # First try with prefix + suffix >> # Then try with prefix only >> # Then try with suffix only, but only for BUILD, and HOST iff REAL_BUILD == REAL_HOST >> @@ -397,17 +404,17 @@ >> # This is needed, because some tools have a prefix and >> # a suffix (eg. gcc), while others may have only one, >> # or even none (eg. binutils) >> - where=$(CT_Which "${t}${tool}${!s}") >> - [ -z "${where}" ] && where=$(CT_Which "${t}${tool}") >> + where=$(CT_Which "${t}${target}${!s}") >> + [ -z "${where}" ] && where=$(CT_Which "${t}${target}") >> if [ -z "${where}" \ >> -a \( "${m}" = "BUILD" \ >> -o "${CT_REAL_BUILD}" = "${!r}" \) ]; then >> - where=$(CT_Which "${tool}${!s}") >> + where=$(CT_Which "${target}${!s}") >> fi >> if [ -z "${where}" \ >> -a \( "${m}" = "BUILD" \ >> -o "${CT_REAL_BUILD}" = "${!r}" \) ]; then >> - where=$(CT_Which "${tool}") >> + where=$(CT_Which "${target}") >> fi >> >> # Not all tools are available for all platforms, but some are really, > > Otherwise, nothing to say. I'll have to look here how it behaves before I > can comment more. As always I thought I'd share the patch to see what others think. I'm happy to carry it locally. -- Michael
diff -r 49af7802dcd5 -r edadd06cb17f config/toolchain.in --- a/config/toolchain.in Tue Nov 22 10:08:10 2011 +0100 +++ b/config/toolchain.in Mon Nov 28 12:56:25 2011 +1300 @@ -247,6 +247,18 @@ for that by checking the tools without the suffix in case it can not find some of the tool. +config BUILD_USE_LSBCC + bool + prompt "| Build using the Linux Standard Base compilers" + help + Set to use the LSB C and C++ compiler wrappers lsbcc and + lsbc++ instead of gcc and g++. + + LSB applications are more portable and should run on any LSB + compliant Linux based operating system. Note that building + against a LSB 3.0 system may require a pre-4.3 version of GCC + and local patches to the LSB build tree. + if CANADIAN comment "Host system" diff -r 49af7802dcd5 -r edadd06cb17f scripts/crosstool-NG.sh.in --- a/scripts/crosstool-NG.sh.in Tue Nov 22 10:08:10 2011 +0100 +++ b/scripts/crosstool-NG.sh.in Mon Nov 28 12:56:25 2011 +1300 @@ -390,6 +390,13 @@ fi for tool in ar as dlltool gcc g++ gcj gnatbind gnatmake ld nm objcopy objdump ranlib strip windres; do + # Re-map GCC and G++ to the corresponding LSB names + case "${CT_BUILD_USE_LSBCC},${m},${tool}" in + y,BUILD,gcc) target="lsbcc";; + y,BUILD,g++) target="lsbc++";; + *) target="${tool}";; + esac + # First try with prefix + suffix # Then try with prefix only # Then try with suffix only, but only for BUILD, and HOST iff REAL_BUILD == REAL_HOST @@ -397,17 +404,17 @@ # This is needed, because some tools have a prefix and # a suffix (eg. gcc), while others may have only one, # or even none (eg. binutils) - where=$(CT_Which "${t}${tool}${!s}") - [ -z "${where}" ] && where=$(CT_Which "${t}${tool}") + where=$(CT_Which "${t}${target}${!s}") + [ -z "${where}" ] && where=$(CT_Which "${t}${target}") if [ -z "${where}" \ -a \( "${m}" = "BUILD" \ -o "${CT_REAL_BUILD}" = "${!r}" \) ]; then - where=$(CT_Which "${tool}${!s}") + where=$(CT_Which "${target}${!s}") fi if [ -z "${where}" \ -a \( "${m}" = "BUILD" \ -o "${CT_REAL_BUILD}" = "${!r}" \) ]; then - where=$(CT_Which "${tool}") + where=$(CT_Which "${target}") fi # Not all tools are available for all platforms, but some are really,
# HG changeset patch # User Michael Hope <michael.hope@linaro.org> # Date 1322438185 -46800 # Branch lsb # Node ID edadd06cb17fd3a45501afe22ae39a76f4a76fa2 # Parent 49af7802dcd538ec3cb64337030b03ac2c6344d2 scripts: support building with the LSB wrappers If set, look for 'lsbcc' instead of 'gcc' and 'lsbc++ instead of g++ and use them when building. The Linux Standard Base defines a set of libraries and APIs that are implemented by most distros. If you build against these APIs then in theory the program can run on any LSB distro instead of just the host. LSB provide a compiler wrapper for the host C and C++ compilers called 'lsbcc' and 'lsbc++'. The wrapper checks the executable name to figure out if you're calling the C or C++ compiler so you have to call these names exactly. Caveats: You need a 4.1 or 4.2 compiler to build. Various parts of the toolchain don't compile LSB 3.0+ header files. Some parts accidentally use the host include files. A patch that works around these is at: http://people.linaro.org/~michaelh/keep/00-crosstool-lsb-hacks.patch Nits: I'm abusing the case statement to do an AND but it makes the default value cleaner. Signed-off-by: Michael Hope <michael.hope@linaro.org>