| Message ID | yddeiah7bd5.fsf@manam.CeBiTec.Uni-Bielefeld.DE |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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.
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 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
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)