public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] scripts: support building with the LSB wrappers
@ 2011-11-27 23:57 Michael Hope
  2011-11-28  0:44 ` Michael Hope
  2011-11-28 18:33 ` Yann E. MORIN
  0 siblings, 2 replies; 4+ messages in thread
From: Michael Hope @ 2011-11-27 23:57 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc, patches

# 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
+      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,

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] scripts: support building with the LSB wrappers
  2011-11-27 23:57 [PATCH] scripts: support building with the LSB wrappers Michael Hope
@ 2011-11-28  0:44 ` Michael Hope
  2011-11-28 18:33 ` Yann E. MORIN
  1 sibling, 0 replies; 4+ messages in thread
From: Michael Hope @ 2011-11-28  0:44 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc, patches

>  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

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] scripts: support building with the LSB wrappers
  2011-11-27 23:57 [PATCH] scripts: support building with the LSB wrappers Michael Hope
  2011-11-28  0:44 ` Michael Hope
@ 2011-11-28 18:33 ` Yann E. MORIN
  2011-11-28 19:20   ` Michael Hope
  1 sibling, 1 reply; 4+ messages in thread
From: Yann E. MORIN @ 2011-11-28 18:33 UTC (permalink / raw)
  To: crossgcc; +Cc: Michael Hope, patches

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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] scripts: support building with the LSB wrappers
  2011-11-28 18:33 ` Yann E. MORIN
@ 2011-11-28 19:20   ` Michael Hope
  0 siblings, 0 replies; 4+ messages in thread
From: Michael Hope @ 2011-11-28 19:20 UTC (permalink / raw)
  To: Yann E. MORIN; +Cc: crossgcc, patches

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-11-28 19:20 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-27 23:57 [PATCH] scripts: support building with the LSB wrappers Michael Hope
2011-11-28  0:44 ` Michael Hope
2011-11-28 18:33 ` Yann E. MORIN
2011-11-28 19:20   ` Michael Hope

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).