[Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Harold Grovesteen]

-------- Original Message --------
Subject: 	Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch
Date: 	Wed, 11 Nov 2009 16:48:23 -0600
From: 	Harold Grovesteen <h.grovsteen@tx.rr.com>
To: 	Mike Frysinger <vapier@gentoo.org>
References: 	<4dfd56aa6ad7b752b3c3.1257961228@dev.site> 
<200911111405.26910.vapier@gentoo.org>





Mike Frysinger wrote:

>On Wednesday 11 November 2009 12:40:28 Harold Grovesteen wrote:
>  
>
>>--- a/scripts/build/libc/glibc.sh	Fri Oct 30 20:08:44 2009 +0100
>>+++ b/scripts/build/libc/glibc.sh	Wed Nov 11 09:07:36 2009 -0600
>>@@ -152,7 +152,8 @@
>>     CT_DoExecLog ALL                                            \
>>     "${CT_SRC_DIR}/glibc-${cvs}${CT_LIBC_VERSION}/configure"    \
>>         --build="${CT_BUILD}"                                   \
>>-        --host="${CT_TARGET}"                                   \
>>+        --host="${CT_BUILD}"                                    \
>>+        --target="${CT_TARGET}"                                 \
>>    
>>
>
>not only is there no --target option for glibc, but it doesnt make any sense 
>for there to be one.  the C library doesnt generate code.
>
>setting the --host to the build system is also blatantly wrong.  i dont see 
>why you need either of these changes -- i cross-compile s390/s390x just fine 
>using the same method as all other targets.
>-mike
>
To both Mike and Yann, this goes to the issue I ran into with 
--with-long-double-128.  Mike, I am glad you can confirm that you don't 
need this.  Now, why did I?  Mike what version of glibc are you using?  
Maybe that is a factor.  I used glibc 2.9.

Mike, are you using crosstool-ng for s390/s390x or your own implementation?

I will make the other recommended changes and remove this.  If the 
problem with long-double-128 returns I will post the results for 
examination.

Thanks all,
Harold Grovesteen


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

Re: [Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2210 bytes --]

On Wednesday 11 November 2009 17:59:28 Harold Grovesteen wrote:
> Mike Frysinger wrote:
> >On Wednesday 11 November 2009 12:40:28 Harold Grovesteen wrote:
> >>--- a/scripts/build/libc/glibc.sh	Fri Oct 30 20:08:44 2009 +0100
> >>+++ b/scripts/build/libc/glibc.sh	Wed Nov 11 09:07:36 2009 -0600
> >>@@ -152,7 +152,8 @@
> >>     CT_DoExecLog ALL                                            \
> >>     "${CT_SRC_DIR}/glibc-${cvs}${CT_LIBC_VERSION}/configure"    \
> >>         --build="${CT_BUILD}"                                   \
> >>-        --host="${CT_TARGET}"                                   \
> >>+        --host="${CT_BUILD}"                                    \
> >>+        --target="${CT_TARGET}"                                 \
> >
> >not only is there no --target option for glibc, but it doesnt make any
> > sense for there to be one.  the C library doesnt generate code.
> >
> >setting the --host to the build system is also blatantly wrong.  i dont
> > see why you need either of these changes -- i cross-compile s390/s390x
> > just fine using the same method as all other targets.
> 
> To both Mike and Yann, this goes to the issue I ran into with
> --with-long-double-128.  Mike, I am glad you can confirm that you don't
> need this.  Now, why did I?  Mike what version of glibc are you using?
> Maybe that is a factor.  I used glibc 2.9.

glibc-2.9 was the last time i tried s390/s390x, and it didnt whine about long 
double issues.  when exactly did you hit troubles ?  during header install and 
thus no C compiler was yet available ?  under Gentoo, a bunch of cache vars 
are forced just for the headers step as there is no compiler to test.  those 
include mlong double tests.
	libc_cv_mlong_double_128=yes
	libc_cv_mlong_double_128ibm=yes

> Mike, are you using crosstool-ng for s390/s390x or your own implementation?

i dont believe ive used crosstool-ng before.  Gentoo has a cross-compiler 
generation tool integrated with its build scripts called crossdev.

> I will make the other recommended changes and remove this.  If the
> problem with long-double-128 returns I will post the results for
> examination.

that would be good
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 582 bytes --]

On Wednesday 11 November 2009 18:37:44 Harold Grovesteen wrote:

please dont use html e-mail

> Mike Frysinger wrote:
> >under Gentoo, a bunch of cache vars
> >are forced just for the headers step as there is no compiler to test. 
> > those include mlong double tests.
> >	libc_cv_mlong_double_128=yes
> >	libc_cv_mlong_double_128ibm=yes
> 
> How do I achieve the equivalent of this with crosstool-ng?

no idea.  yann might know.  just export those vars into the environment.  this 
should be safe to do for all targets during the headers configure step only.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Yann E. MORIN]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

Harold, Mike,
All,

On Saturday 14 November 2009 16:23:18 Mike Frysinger wrote:
> On Wednesday 11 November 2009 18:37:44 Harold Grovesteen wrote:
> > Mike Frysinger wrote:
> > >under Gentoo, a bunch of cache vars
> > >are forced just for the headers step as there is no compiler to test. 
> > > those include mlong double tests.
> > >	libc_cv_mlong_double_128=yes
> > >	libc_cv_mlong_double_128ibm=yes
> > How do I achieve the equivalent of this with crosstool-ng?
> no idea.  yann might know.  just export those vars into the environment.  this 
> should be safe to do for all targets during the headers configure step only.

There is CT_LIBC_GLIBC_CONFIGPARMS that can be set in the menuconfig.
The value set in this variable is used to create a file named 'configparms'
in the top-level of the build dir. That file is then included from the
Makeconfig makefile.

It is possible to use it to pass one value. Passing more is not yet possible.
I can work something to handle more. Care to try the attached patch?

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.  |
`------------------------------^-------^------------------^--------------------'

[-- Attachment #2: ct-ng-many-configparms-values.patch --]
[-- Type: text/x-diff, Size: 1853 bytes --]

diff --git a/config/libc/glibc-eglibc.in-common b/config/libc/glibc-eglibc.in-common
--- a/config/libc/glibc-eglibc.in-common
+++ b/config/libc/glibc-eglibc.in-common
@@ -38,8 +38,8 @@
       
       Unless you are building a toolchain for sh3/4, you should leave that empty.
       
-      Note: this is awkward, and doesn't work well if you need more than one
-            line in configparms
+      Note: If you need to pass more than one value, separate them with
+            '\n'. Eg.:  var1=val1\nvar2=val2
 
 config LIBC_GLIBC_EXTRA_CFLAGS
     string
diff --git a/scripts/build/libc/glibc.sh b/scripts/build/libc/glibc.sh
--- a/scripts/build/libc/glibc.sh
+++ b/scripts/build/libc/glibc.sh
@@ -141,7 +141,7 @@
     extra_config+=("$(do_libc_min_kernel_config)")
 
     # Pre-seed the configparms file with values from the config option
-    echo "${CT_LIBC_GLIBC_CONFIGPARMS}" > configparms
+    printf "${CT_LIBC_GLIBC_CONFIGPARMS}" > configparms
 
     cross_cc=$(CT_Which "${CT_TARGET}-gcc")
     CT_DoLog DEBUG "Using gcc for target: '${cross_cc}'"
@@ -309,7 +309,7 @@
     CT_DoLog DEBUG "Extra CC args passed    : '${extra_cc_args}'"
 
     # Pre-seed the configparms file with values from the config option
-    echo "${CT_LIBC_GLIBC_CONFIGPARMS}" > configparms
+    printf "${CT_LIBC_GLIBC_CONFIGPARMS}" > configparms
 
     echo "libc_cv_forced_unwind=yes" > config.cache
     echo "libc_cv_c_cleanup=yes" >> config.cache
@@ -418,7 +418,7 @@
     CT_DoLog DEBUG "Extra CC args passed    : '${extra_cc_args}'"
 
     # Pre-seed the configparms file with values from the config option
-    echo "${CT_LIBC_GLIBC_CONFIGPARMS}" > configparms
+    printf "${CT_LIBC_GLIBC_CONFIGPARMS}" > configparms
 
     # For glibc 2.3.4 and later we need to set some autoconf cache
     # variables, because nptl/sysdeps/pthread/configure.in does not


[-- Attachment #3: Type: text/plain, Size: 71 bytes --]

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

Re: [Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1460 bytes --]

On Saturday 14 November 2009 10:56:19 Yann E. MORIN wrote:
> On Saturday 14 November 2009 16:23:18 Mike Frysinger wrote:
> > On Wednesday 11 November 2009 18:37:44 Harold Grovesteen wrote:
> > > Mike Frysinger wrote:
> > > >under Gentoo, a bunch of cache vars
> > > >are forced just for the headers step as there is no compiler to test.
> > > > those include mlong double tests.
> > > >	libc_cv_mlong_double_128=yes
> > > >	libc_cv_mlong_double_128ibm=yes
> > >
> > > How do I achieve the equivalent of this with crosstool-ng?
> >
> > no idea.  yann might know.  just export those vars into the environment. 
> > this should be safe to do for all targets during the headers configure
> > step only.
> 
> There is CT_LIBC_GLIBC_CONFIGPARMS that can be set in the menuconfig.
> The value set in this variable is used to create a file named 'configparms'
> in the top-level of the build dir. That file is then included from the
> Makeconfig makefile.
> 
> It is possible to use it to pass one value. Passing more is not yet
>  possible. I can work something to handle more. Care to try the attached
>  patch?

these are settings that should always be there and the user shouldnt be forced 
to configure themselves.  it also isnt specific to s390 ... it comes up with 
ppc targets too.

for the headers step, it's safe to export these all the time for all targets.  
we've been doing this in gentoo for quite a long time now.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Harold Grovesteen]

Mike Frysinger wrote:

>On Saturday 14 November 2009 10:56:19 Yann E. MORIN wrote:
>  
>
>>On Saturday 14 November 2009 16:23:18 Mike Frysinger wrote:
>>    
>>
>>>On Wednesday 11 November 2009 18:37:44 Harold Grovesteen wrote:
>>>      
>>>
>>>>Mike Frysinger wrote:
>>>>        
>>>>
>>>>>under Gentoo, a bunch of cache vars
>>>>>are forced just for the headers step as there is no compiler to test.
>>>>>those include mlong double tests.
>>>>>	libc_cv_mlong_double_128=yes
>>>>>	libc_cv_mlong_double_128ibm=yes
>>>>>          
>>>>>
>>>>How do I achieve the equivalent of this with crosstool-ng?
>>>>        
>>>>
>>>no idea.  yann might know.  just export those vars into the environment. 
>>>this should be safe to do for all targets during the headers configure
>>>step only.
>>>      
>>>
>>There is CT_LIBC_GLIBC_CONFIGPARMS that can be set in the menuconfig.
>>The value set in this variable is used to create a file named 'configparms'
>>in the top-level of the build dir. That file is then included from the
>>Makeconfig makefile.
>>
>>It is possible to use it to pass one value. Passing more is not yet
>> possible. I can work something to handle more. Care to try the attached
>> patch?
>>    
>>
>
>these are settings that should always be there and the user shouldnt be forced 
>to configure themselves.  it also isnt specific to s390 ... it comes up with 
>ppc targets too.
>
>for the headers step, it's safe to export these all the time for all targets.  
>we've been doing this in gentoo for quite a long time now.
>-mike
>
I have not been able to reproduce this issue.  I even recloned the 
repository, rebuilt crosstool-ng and used my finalized .in's .sh's and 
samples.  Worked fine out of the shoot.  I am very close to posting a 
new patch.

Harold


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

Re: [Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 442 bytes --]

On Saturday 14 November 2009 15:54:28 Harold Grovesteen wrote:
> I have not been able to reproduce this issue.  I even recloned the
> repository, rebuilt crosstool-ng and used my finalized .in's .sh's and
> samples.  Worked fine out of the shoot.  I am very close to posting a
> new patch.

might want to make sure you didnt have a toolchain in your path the second 
time through which would allow the configure tests to pass.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Yann E. MORIN]

On Saturday 14 November 2009 17:28:26 Mike Frysinger wrote:
> > > > Mike Frysinger wrote:
> > > > >under Gentoo, a bunch of cache vars
> > > > >are forced just for the headers step as there is no compiler to test.
> > > > > those include mlong double tests.
> > > > >	libc_cv_mlong_double_128=yes
> > > > >	libc_cv_mlong_double_128ibm=yes
> these are settings that should always be there and the user shouldnt be forced 
> to configure themselves.  it also isnt specific to s390 ... it comes up with 
> ppc targets too.
> for the headers step, it's safe to export these all the time for all targets.  
> we've been doing this in gentoo for quite a long time now.

You mean unconditionally? On my x86_64 machine, debian lenny:
- in 64-bit mode: sizeof( long double ) = 16 bytes = 128 bits
- in 32-bit mode: sizeof( long double ) = 12 bytes =  96 bits

So, does it really makes sense to _unconditionnally_ set long-double-128?
The gcc man page says that on x86 (32-bit) the ABI specifies a size of
96 bits for long double.

Also, what does long-double-128ibm means?

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

Re: [Fwd: Re: [PATCH 1 of 3] arch: s390 and 390x glibc patch]

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1469 bytes --]

On Saturday 14 November 2009 19:36:44 Yann E. MORIN wrote:
> On Saturday 14 November 2009 17:28:26 Mike Frysinger wrote:
> > > > > Mike Frysinger wrote:
> > > > > >under Gentoo, a bunch of cache vars
> > > > > >are forced just for the headers step as there is no compiler to
> > > > > > test. those include mlong double tests.
> > > > > >	libc_cv_mlong_double_128=yes
> > > > > >	libc_cv_mlong_double_128ibm=yes
> >
> > these are settings that should always be there and the user shouldnt be
> > forced to configure themselves.  it also isnt specific to s390 ... it
> > comes up with ppc targets too.
> > for the headers step, it's safe to export these all the time for all
> > targets. we've been doing this in gentoo for quite a long time now.
> 
> You mean unconditionally? On my x86_64 machine, debian lenny:
> - in 64-bit mode: sizeof( long double ) = 16 bytes = 128 bits
> - in 32-bit mode: sizeof( long double ) = 12 bytes =  96 bits
> 
> So, does it really makes sense to _unconditionnally_ set long-double-128?
> The gcc man page says that on x86 (32-bit) the ABI specifies a size of
> 96 bits for long double.
> 
> Also, what does long-double-128ibm means?

i mean what i said.  if you read the glibc configure script, you'll see these 
are simply toolchain sanity checks.  they dont affect header generation in any 
way.  the sizeof long double is also irrelevant -- which you'll see when you 
read the configure scripts.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]