[fortran, build] Fix libquadmath build on Solaris 2

[fortran, build] Fix libquadmath build on Solaris 2

[Rainer Orth]

As discussed in this thread

	http://gcc.gnu.org/ml/gcc/2010-11/msg00422.html

the following patch restores Solaris 2 bootstrap in libquadmath.  It was
created with diff -wup to avoid obscuring it by the whitespace
differences.

Successfully bootstrapped on i386-pc-solaris2.10, though all 64-bit
Fortran execution tests still fail as described above.

For the time being, I'm moving -lm from _LIBADD to _LDFLAGS, as is
already done in libjava/Makefile.am.  Depending on the outcome of
further discussions, this might be handled in contrib/make_sunver.pl in
the future.

Installed.

	Rainer


2010-11-18  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* Makefile.am (libquadmath_la_LIBADD): Move -lm ...
	(libquadmath_la_LDFLAGS): ... here.
	(quadmath.map-sun): Tabify.
	Fix sed expression.
	* Makefile.in: Regenerate.

--- local.9fa5269f2518/libquadmath/Makefile.am	2010-11-19 13:15:10.802866291 +0100
+++ /vol/gcc/src/hg/trunk/local/libquadmath/Makefile.am	2010-11-18 18:29:42.000000000 +0100
@@ -24,9 +24,8 @@ quadmath.map-sun : $(srcdir)/quadmath.ma
                 $(libquadmath_la_OBJECTS) $(libquadmath_la_LIBADD)
         perl $(top_srcdir)/../contrib/make_sunver.pl \
           $(srcdir)/quadmath.map \
-          $(libquadmath_la_OBJECTS:%.lo=.libs/%.o) \
-         `echo $(libquadmath_la_LIBADD) | \
-            sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
+	 `echo $(libquadmath_la_OBJECTS) $(libquadmath_la_LIBADD) | \
+	   sed 's,\([^/ 	]*\)\.l\([ao]\),.libs/\1.\2,g'` \
          > $@ || (rm -f $@ ; exit 1)
 endif
 else
@@ -39,8 +38,8 @@ LTLDFLAGS = $(shell $(SHELL) $(top_srcdi
 
 
 toolexeclib_LTLIBRARIES = libquadmath.la
-libquadmath_la_LIBADD = -lm
-libquadmath_la_LDFLAGS = $(LTLDFLAGS) -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(version_arg)
+libquadmath_la_LIBADD = 
+libquadmath_la_LDFLAGS = $(LTLDFLAGS) -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(version_arg) -lm
 libquadmath_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
 libquadmath_la_DEPENDENCIES = $(version_dep)
 
-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [fortran, build] Fix libquadmath build on Solaris 2

[Tobias Burnus]

On 11/19/2010 01:21 PM, Rainer Orth wrote:
> As discussed in this thread
> 	http://gcc.gnu.org/ml/gcc/2010-11/msg00422.html

Isn't that kind of superseded by my (still unreviewed) patch from 
Wednesday at
    http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01851.html

The latter patch allows to build libquadmath with the cross compiler - 
and includes your -lm change.

Tobias

Re: [fortran, build] Fix libquadmath build on Solaris 2

[Rainer Orth]

Tobias Burnus <burnus@net-b.de> writes:

> On 11/19/2010 01:21 PM, Rainer Orth wrote:
>> As discussed in this thread
>> 	http://gcc.gnu.org/ml/gcc/2010-11/msg00422.html
>
> Isn't that kind of superseded by my (still unreviewed) patch from Wednesday
> at
>    http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01851.html
>
> The latter patch allows to build libquadmath with the cross compiler - 
> and includes your -lm change.

While the -lm change is included in your patch (and your
quadmath.map-sun change hopefully currectly uses TABs instead of
spaces), the sed expression for .l[ao] -> .[ao] conversion is still
wrong for object files in subdirectories.  The part with
HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT is completely unnecessary
since this is unused inside libquadmath (as in libgfortran).  Right now
there's no need to convert from the libgfortran symbol versioning
machinery to the libgomp one, so please leave this alone: what we have
right now simply works AFAIK.

I still mean to unify the different diverging copies of that stuff (and
the two different families, one in libstdc++-v3 and libgomp, the other
in libgfortran, libssp, libjava and now libquadmath) and put them in a
single place to have a template for adding symbol versioning support to
libffi and libobjc, but that's certainly not stage3 stuff.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [fortran, build] Fix libquadmath build on Solaris 2

[Ralf Wildenhues]

Hello Rainer,

* Rainer Orth wrote on Fri, Nov 19, 2010 at 03:07:37PM CET:
> I still mean to unify the different diverging copies of that stuff (and
> the two different families, one in libstdc++-v3 and libgomp, the other
> in libgfortran, libssp, libjava and now libquadmath) and put them in a
> single place to have a template for adding symbol versioning support to
> libffi and libobjc, but that's certainly not stage3 stuff.

I know we went completely silent at the time (I tried to, but simply
never found the time to look into this; sorry), but we *could*
reconsider moving such functionality to Libtool eventually, you know.

Of course I cannot expect you to agree nor do this work, and I still
cannot promise a lot of time, but I think it might be the right idea
conceptually.

Cheers,
Ralf

Re: [fortran, build] Fix libquadmath build on Solaris 2

[Rainer Orth]

Hi Ralf,

> * Rainer Orth wrote on Fri, Nov 19, 2010 at 03:07:37PM CET:
>> I still mean to unify the different diverging copies of that stuff (and
>> the two different families, one in libstdc++-v3 and libgomp, the other
>> in libgfortran, libssp, libjava and now libquadmath) and put them in a
>> single place to have a template for adding symbol versioning support to
>> libffi and libobjc, but that's certainly not stage3 stuff.
>
> I know we went completely silent at the time (I tried to, but simply
> never found the time to look into this; sorry), but we *could*
> reconsider moving such functionality to Libtool eventually, you know.

it's just as much my fault: when you followed up to my suggestion to do
this, I didn't have the time to respond.  But I still think this is the
right course going forward, so libraries/projects outsite of GCC can
benefit from this.  It seems to me, though, that it will have to be both
Automake and Libtool, but a detailed design will have to wait.

> Of course I cannot expect you to agree nor do this work, and I still
> cannot promise a lot of time, but I think it might be the right idea
> conceptually.

Fully agreed.  It seems to me that the first step has to be to
generalize what is currently in GCC, try it on additional libraries (I
still plan to do libffi and libobjc at some point), and if this works
out, thing about moving it to Automake/Libtool instead.

This is certainly 4.7 material, though.  I hope to get around to this in
that timeframe, provided libobjc stabilizes enough by than to make it
worthwhile.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [fortran, build] Fix libquadmath build on Solaris 2

[NightStrike]

On Mon, Nov 22, 2010 at 12:02 PM, Rainer Orth
<ro@cebitec.uni-bielefeld.de> wrote:
> Hi Ralf,
>
>> * Rainer Orth wrote on Fri, Nov 19, 2010 at 03:07:37PM CET:
>>> I still mean to unify the different diverging copies of that stuff (and
>>> the two different families, one in libstdc++-v3 and libgomp, the other
>>> in libgfortran, libssp, libjava and now libquadmath) and put them in a
>>> single place to have a template for adding symbol versioning support to
>>> libffi and libobjc, but that's certainly not stage3 stuff.
>>
>> I know we went completely silent at the time (I tried to, but simply
>> never found the time to look into this; sorry), but we *could*
>> reconsider moving such functionality to Libtool eventually, you know.
>
> it's just as much my fault: when you followed up to my suggestion to do
> this, I didn't have the time to respond.  But I still think this is the
> right course going forward, so libraries/projects outsite of GCC can
> benefit from this.  It seems to me, though, that it will have to be both
> Automake and Libtool, but a detailed design will have to wait.
>
>> Of course I cannot expect you to agree nor do this work, and I still
>> cannot promise a lot of time, but I think it might be the right idea
>> conceptually.
>
> Fully agreed.  It seems to me that the first step has to be to
> generalize what is currently in GCC, try it on additional libraries (I
> still plan to do libffi and libobjc at some point), and if this works
> out, thing about moving it to Automake/Libtool instead.
>
> This is certainly 4.7 material, though.  I hope to get around to this in
> that timeframe, provided libobjc stabilizes enough by than to make it
> worthwhile.

Can you file a PR so that it's not forgotten?  Untracked ideas tend to
get forgotten.

Re: [fortran, build] Fix libquadmath build on Solaris 2

[Rainer Orth]

NightStrike <nightstrike@gmail.com> writes:

>> Fully agreed.  It seems to me that the first step has to be to
>> generalize what is currently in GCC, try it on additional libraries (I
>> still plan to do libffi and libobjc at some point), and if this works
>> out, thing about moving it to Automake/Libtool instead.
>>
>> This is certainly 4.7 material, though.  I hope to get around to this in
>> that timeframe, provided libobjc stabilizes enough by than to make it
>> worthwhile.
>
> Can you file a PR so that it's not forgotten?  Untracked ideas tend to
> get forgotten.

No need: it's already on my agenda, and it seems quite unlikely that
anyone else plans to take this on.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [fortran, build] Fix libquadmath build on Solaris 2

[Ralf Wildenhues]

* Rainer Orth wrote on Mon, Nov 22, 2010 at 06:02:47PM CET:
> > * Rainer Orth wrote on Fri, Nov 19, 2010 at 03:07:37PM CET:
> >> I still mean to unify the different diverging copies of that stuff (and
> >> the two different families, one in libstdc++-v3 and libgomp, the other
> >> in libgfortran, libssp, libjava and now libquadmath) and put them in a
> >> single place to have a template for adding symbol versioning support to
> >> libffi and libobjc, but that's certainly not stage3 stuff.
> >
> > I know we went completely silent at the time (I tried to, but simply
> > never found the time to look into this; sorry), but we *could*
> > reconsider moving such functionality to Libtool eventually, you know.
> 
> it's just as much my fault: when you followed up to my suggestion to do
> this, I didn't have the time to respond.  But I still think this is the
> right course going forward, so libraries/projects outsite of GCC can
> benefit from this.  It seems to me, though, that it will have to be both
> Automake and Libtool,

Likely, yes.

> but a detailed design will have to wait.

OK.

> > Of course I cannot expect you to agree nor do this work, and I still
> > cannot promise a lot of time, but I think it might be the right idea
> > conceptually.
> 
> Fully agreed.  It seems to me that the first step has to be to
> generalize what is currently in GCC, try it on additional libraries (I
> still plan to do libffi and libobjc at some point), and if this works
> out, thing about moving it to Automake/Libtool instead.
> 
> This is certainly 4.7 material, though.

Agreed on all points.

> I hope to get around to this in
> that timeframe, provided libobjc stabilizes enough by than to make it
> worthwhile.

Cool.

Thanks!
Ralf