[PATCH] scripts: support building with the LSB wrappers

[Michael Hope]

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

--
For unsubscribe information see http://sourceware.org/lists.html#faq