Bug#361219: patch
tags 361219 patch
thanks
The attached patch makes the build always use -fPIC.
Bastian
--
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4
diff -u r-base-2.2.1.svn37642/debian/changelog
r-base-2.2.1.svn37642/debian/changelog
--- r-base-2.2.1.svn37642/debian/changelog
+++ r-base-2.2.1.svn37642/debian/changelog
@@ -1,3 +1,10 @@
+r-base (2.2.1.svn37642-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Always build with -fPIC. (closes: #361219)
+
+ -- Bastian Blank <[EMAIL PROTECTED]> Fri, 7 Apr 2006 08:59:15 +
+
r-base (2.2.1.svn37642-1) unstable; urgency=low
* First alpha release of the upcoming R 2.3.0 planned for April 24
only in patch2:
unchanged:
--- r-base-2.2.1.svn37642.orig/configure
+++ r-base-2.2.1.svn37642/configure
@@ -29630,39 +29630,14 @@
## Step 2. GNU compilers.
if test "${GCC}" = yes; then
- case "${host_cpu}" in
-## Sparc has only an 8k global object table, 1024 entries on 64-bit.
-## PowerPC has 32k, not enough on ppc64 for the ca6200 entries in libR.so
-## The only other platform where this is said to matter is m68k, which
-## has 32k and so can use -fpic.
-sparc*|ppc64)
- cpicflags="-fPIC"
- ;;
-*)
- cpicflags="-fpic"
- ;;
- esac
+ cpicflags="-fPIC"
shlib_ldflags="-shared"
fi
if test "${G77}" = yes; then
- case "${host_cpu}" in
-sparc*|ppc64)
- fpicflags="-fPIC"
- ;;
-*)
- fpicflags="-fpic"
- ;;
- esac
+ fpicflags="-fPIC"
fi
if test "${GXX}" = yes; then
- case "${host_cpu}" in
-sparc*|ppc64)
- cxxpicflags="-fPIC"
- ;;
-*)
- cxxpicflags="-fpic"
- ;;
- esac
+ cxxpicflags="-fPIC"
shlib_cxxldflags="-shared"
fi
@@ -43254,14 +43229,7 @@
## Debian in their wisdom have f95 as a link to gfortran, so
## use this to pick out gfortran (even though it is unreliable).
if test "${ac_cv_fc_compiler_gnu}" = yes; then
- case "${host_cpu}" in
-sparc*|ppc64)
- fcpicflags="-fPIC"
- ;;
-*)
- fcpicflags="-fpic"
- ;;
- esac
+ fcpicflags="-fPIC"
fi
case "${host_os}" in
darwin*)
only in patch2:
unchanged:
--- r-base-2.2.1.svn37642.orig/configure.ac
+++ r-base-2.2.1.svn37642/configure.ac
@@ -1066,39 +1066,14 @@
## Step 2. GNU compilers.
if test "${GCC}" = yes; then
- case "${host_cpu}" in
-## Sparc has only an 8k global object table, 1024 entries on 64-bit.
-## PowerPC has 32k, not enough on ppc64 for the ca6200 entries in libR.so
-## The only other platform where this is said to matter is m68k, which
-## has 32k and so can use -fpic.
-sparc*|ppc64)
- cpicflags="-fPIC"
- ;;
-*)
- cpicflags="-fpic"
- ;;
- esac
+ cpicflags="-fPIC"
shlib_ldflags="-shared"
fi
if test "${G77}" = yes; then
- case "${host_cpu}" in
-sparc*|ppc64)
- fpicflags="-fPIC"
- ;;
-*)
- fpicflags="-fpic"
- ;;
- esac
+ fpicflags="-fPIC"
fi
if test "${GXX}" = yes; then
- case "${host_cpu}" in
-sparc*|ppc64)
- cxxpicflags="-fPIC"
- ;;
-*)
- cxxpicflags="-fpic"
- ;;
- esac
+ cxxpicflags="-fPIC"
shlib_cxxldflags="-shared"
fi
@@ -1718,14 +1693,7 @@
## Debian in their wisdom have f95 as a link to gfortran, so
## use this to pick out gfortran (even though it is unreliable).
if test "${ac_cv_fc_compiler_gnu}" = yes; then
- case "${host_cpu}" in
-sparc*|ppc64)
- fcpicflags="-fPIC"
- ;;
-*)
- fcpicflags="-fpic"
- ;;
- esac
+ fcpicflags="-fPIC"
fi
case "${host_os}" in
darwin*)
signature.asc
Description: Digital signature
Bug#361219: patch
Kurt: Here is the patch.
Bastian: http://buildd.debian.org/build.php?pkg=r-base shows builds
succeeding everywhere but s390 [and m68k at the very end which looks like a
local issue: dh_fixperms just died...] I am still a bit suspicious of your
brute force replacement of -fpic. Or do you know for sure that gcc 4.*
requires it? Should it then be conditional on gcc/g++ versions be larger
than a threshold?
Dirk
On 7 April 2006 at 11:14, Bastian Blank wrote:
| tags 361219 patch
| thanks
|
| The attached patch makes the build always use -fPIC.
|
| Bastian
|
| --
| Violence in reality is quite different from theory.
| -- Spock, "The Cloud Minders", stardate 5818.4
| diff -u r-base-2.2.1.svn37642/debian/changelog
r-base-2.2.1.svn37642/debian/changelog
| --- r-base-2.2.1.svn37642/debian/changelog
| +++ r-base-2.2.1.svn37642/debian/changelog
| @@ -1,3 +1,10 @@
| +r-base (2.2.1.svn37642-1.1) unstable; urgency=low
| +
| + * Non-maintainer upload.
| + * Always build with -fPIC. (closes: #361219)
| +
| + -- Bastian Blank <[EMAIL PROTECTED]> Fri, 7 Apr 2006 08:59:15 +
| +
| r-base (2.2.1.svn37642-1) unstable; urgency=low
|
|* First alpha release of the upcoming R 2.3.0 planned for April 24
| only in patch2:
| unchanged:
| --- r-base-2.2.1.svn37642.orig/configure
| +++ r-base-2.2.1.svn37642/configure
| @@ -29630,39 +29630,14 @@
|
| ## Step 2. GNU compilers.
| if test "${GCC}" = yes; then
| - case "${host_cpu}" in
| -## Sparc has only an 8k global object table, 1024 entries on 64-bit.
| -## PowerPC has 32k, not enough on ppc64 for the ca6200 entries in libR.so
| -## The only other platform where this is said to matter is m68k, which
| -## has 32k and so can use -fpic.
| -sparc*|ppc64)
| - cpicflags="-fPIC"
| - ;;
| -*)
| - cpicflags="-fpic"
| - ;;
| - esac
| + cpicflags="-fPIC"
|shlib_ldflags="-shared"
| fi
| if test "${G77}" = yes; then
| - case "${host_cpu}" in
| -sparc*|ppc64)
| - fpicflags="-fPIC"
| - ;;
| -*)
| - fpicflags="-fpic"
| - ;;
| - esac
| + fpicflags="-fPIC"
| fi
| if test "${GXX}" = yes; then
| - case "${host_cpu}" in
| -sparc*|ppc64)
| - cxxpicflags="-fPIC"
| - ;;
| -*)
| - cxxpicflags="-fpic"
| - ;;
| - esac
| + cxxpicflags="-fPIC"
|shlib_cxxldflags="-shared"
| fi
|
| @@ -43254,14 +43229,7 @@
| ## Debian in their wisdom have f95 as a link to gfortran, so
| ## use this to pick out gfortran (even though it is unreliable).
| if test "${ac_cv_fc_compiler_gnu}" = yes; then
| - case "${host_cpu}" in
| -sparc*|ppc64)
| - fcpicflags="-fPIC"
| - ;;
| -*)
| - fcpicflags="-fpic"
| - ;;
| - esac
| + fcpicflags="-fPIC"
| fi
| case "${host_os}" in
|darwin*)
| only in patch2:
| unchanged:
| --- r-base-2.2.1.svn37642.orig/configure.ac
| +++ r-base-2.2.1.svn37642/configure.ac
| @@ -1066,39 +1066,14 @@
|
| ## Step 2. GNU compilers.
| if test "${GCC}" = yes; then
| - case "${host_cpu}" in
| -## Sparc has only an 8k global object table, 1024 entries on 64-bit.
| -## PowerPC has 32k, not enough on ppc64 for the ca6200 entries in libR.so
| -## The only other platform where this is said to matter is m68k, which
| -## has 32k and so can use -fpic.
| -sparc*|ppc64)
| - cpicflags="-fPIC"
| - ;;
| -*)
| - cpicflags="-fpic"
| - ;;
| - esac
| + cpicflags="-fPIC"
|shlib_ldflags="-shared"
| fi
| if test "${G77}" = yes; then
| - case "${host_cpu}" in
| -sparc*|ppc64)
| - fpicflags="-fPIC"
| - ;;
| -*)
| - fpicflags="-fpic"
| - ;;
| - esac
| + fpicflags="-fPIC"
| fi
| if test "${GXX}" = yes; then
| - case "${host_cpu}" in
| -sparc*|ppc64)
| - cxxpicflags="-fPIC"
| - ;;
| -*)
| - cxxpicflags="-fpic"
| - ;;
| - esac
| + cxxpicflags="-fPIC"
|shlib_cxxldflags="-shared"
| fi
|
| @@ -1718,14 +1693,7 @@
| ## Debian in their wisdom have f95 as a link to gfortran, so
| ## use this to pick out gfortran (even though it is unreliable).
| if test "${ac_cv_fc_compiler_gnu}" = yes; then
| - case "${host_cpu}" in
| -sparc*|ppc64)
| - fcpicflags="-fPIC"
| - ;;
| -*)
| - fcpicflags="-fpic"
| - ;;
| - esac
| + fcpicflags="-fPIC"
| fi
| case "${host_os}" in
|darwin*)
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361219: patch
On Fri, Apr 07, 2006 at 06:27:25AM -0500, Dirk Eddelbuettel wrote: >I am still a bit suspicious of your > brute force replacement of -fpic. Or do you know for sure that gcc 4.* > requires it? Should it then be conditional on gcc/g++ versions be larger > than a threshold? It is not related to the compiler version. -fpic is documented to have limitations on some systems and is not reliable on some of them for larger software. The usage of -fPIC enables the use of other relocation types which don't have this limitations (or much larger). On most arches it don't make any difference at all. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9 signature.asc Description: Digital signature
Bug#361219: patch
[ Let's PLEASE all keep the mail headers in tact. My bad for not including Brian earlier, so if possible could all future mails please include Bastian, Dirk, Kurt, Brian and the BTS as for this mail ? ] [ Bastian, I'll send you two emails by Brian. Please consider those before replying. We may also want to get Mathias (Debian and Ubuntu gcc maintainer) involved. ] On 7 April 2006 at 13:41, Bastian Blank wrote: | On Fri, Apr 07, 2006 at 06:27:25AM -0500, Dirk Eddelbuettel wrote: | >I am still a bit suspicious of your | > brute force replacement of -fpic. Or do you know for sure that gcc 4.* | > requires it? Should it then be conditional on gcc/g++ versions be larger | > than a threshold? | | It is not related to the compiler version. -fpic is documented to have | limitations on some systems and is not reliable on some of them for | larger software. The usage of -fPIC enables the use of other relocation | types which don't have this limitations (or much larger). On most arches | it don't make any difference at all. Bastian, could you please document on which architectures, and for which gcc versions, this fails? R actually has a pretty darn good record of building on many platforms and gcc variants, as well as a few non gcc compilers, so I do not want to discard the accumulated experience from the R side this early. I'm sure we get this resolved in a way that makes everybody happy, and gets R to build everywhere. Thanks, Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361219: patch
Dirk, [I didn't get reusable headers from Kurt as he forwarded an attachment.] This was changed based on quite explicit advice in Ulrich Drepper's DSO paper to use -fpic wherever possible as it can be lot faster. See http://people.redhat.com/drepper/dsohowto.pdf, e.g. `-fpic should be used at all times unless it is absolutely necessary to use -fPIC'. This was part of a concerted effort to close the performance gap between standalone and shared-library versions of R (and we seem to have about halved it). ppc32 is a platform where R can be compiled with -fpic and it does have a performance advantage. So in principle does m68k, but I last used that in 1989. (We have been told that the Apple versions of gcc have -fpic = -fPIC on ppc.) I would be very reluctant to change back to -fPIC everywhere, although an alternative approach would be to make -fPIC the default and use -fpic on ppc32 and m68k. Brian On Fri, 7 Apr 2006, Dirk Eddelbuettel wrote: [ Let's PLEASE all keep the mail headers in tact. My bad for not including Brian earlier, so if possible could all future mails please include Bastian, Dirk, Kurt, Brian and the BTS as for this mail ? ] [ Bastian, I'll send you two emails by Brian. Please consider those before replying. We may also want to get Mathias (Debian and Ubuntu gcc maintainer) involved. ] On 7 April 2006 at 13:41, Bastian Blank wrote: | On Fri, Apr 07, 2006 at 06:27:25AM -0500, Dirk Eddelbuettel wrote: | >I am still a bit suspicious of your | > brute force replacement of -fpic. Or do you know for sure that gcc 4.* | > requires it? Should it then be conditional on gcc/g++ versions be larger | > than a threshold? | | It is not related to the compiler version. -fpic is documented to have | limitations on some systems and is not reliable on some of them for | larger software. The usage of -fPIC enables the use of other relocation | types which don't have this limitations (or much larger). On most arches | it don't make any difference at all. Bastian, could you please document on which architectures, and for which gcc versions, this fails? R actually has a pretty darn good record of building on many platforms and gcc variants, as well as a few non gcc compilers, so I do not want to discard the accumulated experience from the R side this early. I'm sure we get this resolved in a way that makes everybody happy, and gets R to build everywhere. Thanks, Dirk -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361219: patch
Hi Brian, On 7 April 2006 at 15:40, Prof Brian Ripley wrote: | Dirk, | | [I didn't get reusable headers from Kurt as he forwarded an attachment.] (Sure, I was just trying to streamline between Bastian, Kurt and myself seemingly emailing at the same time...) | | This was changed based on quite explicit advice in Ulrich Drepper's | DSO paper to use -fpic wherever possible as it can be lot faster. | See http://people.redhat.com/drepper/dsohowto.pdf, e.g. | | `-fpic should be used at all times unless it is absolutely necessary to | use -fPIC'. | | This was part of a concerted effort to close the performance gap between | standalone and shared-library versions of R (and we seem to have about | halved it). Good enough reason for me. | ppc32 is a platform where R can be compiled with -fpic and it does have a | performance advantage. So in principle does m68k, but I last used that in | 1989. (We have been told that the Apple versions of gcc have -fpic = | -fPIC on ppc.) | | I would be very reluctant to change back to -fPIC everywhere, although an | alternative approach would be to make -fPIC the default and use -fpic on | ppc32 and m68k. So what shall we do? I would be happy to try either one of the two approaches you suggest to see what s390 does with it. Regards, Dirk | Brian | | On Fri, 7 Apr 2006, Dirk Eddelbuettel wrote: | | > | > [ Let's PLEASE all keep the mail headers in tact. My bad for not including | > Brian earlier, so if possible could all future mails please include Bastian, | > Dirk, Kurt, Brian and the BTS as for this mail ? ] | > | > [ Bastian, I'll send you two emails by Brian. Please consider those before | > replying. We may also want to get Mathias (Debian and Ubuntu gcc maintainer) | > involved. ] | > | > On 7 April 2006 at 13:41, Bastian Blank wrote: | > | On Fri, Apr 07, 2006 at 06:27:25AM -0500, Dirk Eddelbuettel wrote: | > | >I am still a bit suspicious of your | > | > brute force replacement of -fpic. Or do you know for sure that gcc 4.* | > | > requires it? Should it then be conditional on gcc/g++ versions be larger | > | > than a threshold? | > | | > | It is not related to the compiler version. -fpic is documented to have | > | limitations on some systems and is not reliable on some of them for | > | larger software. The usage of -fPIC enables the use of other relocation | > | types which don't have this limitations (or much larger). On most arches | > | it don't make any difference at all. | > | > Bastian, could you please document on which architectures, and for which gcc | > versions, this fails? R actually has a pretty darn good record of building | > on many platforms and gcc variants, as well as a few non gcc compilers, so I | > do not want to discard the accumulated experience from the R side this | > early. | > | > I'm sure we get this resolved in a way that makes everybody happy, and gets R | > to build everywhere. | > | > Thanks, Dirk | > | > | | -- | Brian D. Ripley, [EMAIL PROTECTED] | Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ | University of Oxford, Tel: +44 1865 272861 (self) | 1 South Parks Road, +44 1865 272866 (PA) | Oxford OX1 3TG, UKFax: +44 1865 272595 -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361219: patch
On Fri, 7 Apr 2006, Dirk Eddelbuettel wrote: Hi Brian, On 7 April 2006 at 15:40, Prof Brian Ripley wrote: | Dirk, | | [I didn't get reusable headers from Kurt as he forwarded an attachment.] (Sure, I was just trying to streamline between Bastian, Kurt and myself seemingly emailing at the same time...) | | This was changed based on quite explicit advice in Ulrich Drepper's | DSO paper to use -fpic wherever possible as it can be lot faster. | See http://people.redhat.com/drepper/dsohowto.pdf, e.g. | | `-fpic should be used at all times unless it is absolutely necessary to | use -fPIC'. | | This was part of a concerted effort to close the performance gap between | standalone and shared-library versions of R (and we seem to have about | halved it). Good enough reason for me. | ppc32 is a platform where R can be compiled with -fpic and it does have a | performance advantage. So in principle does m68k, but I last used that in | 1989. (We have been told that the Apple versions of gcc have -fpic = | -fPIC on ppc.) | | I would be very reluctant to change back to -fPIC everywhere, although an | alternative approach would be to make -fPIC the default and use -fpic on | ppc32 and m68k. So what shall we do? I would be happy to try either one of the two approaches you suggest to see what s390 does with it. Yesterday I added s390* to the list of platforms which need -fPIC in configure. The problem ought to be solved if I did that in all the needed places (which I think I did), so can someone try the current 2.3.0 alpha on s390? We still need evidence of the various claims about -fpic vs -fPIC on s390. Although I found some evidence of -fPIC being needed in some cases elsewhere (and even more so on s390x than s390), could not even find the GOT size. Bastian claimed -fpic is documented to have limitations on some systems and is not reliable on some of them for larger software. Just where *is* this documented for s390, since it is a gcc flag and it is not (I am pretty sure) in the gcc documentation (which I have just been grepping)? Brian -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361219: patch
On 8 April 2006 at 08:08, Prof Brian D Ripley wrote: | > So what shall we do? I would be happy to try either one of the two | > approaches you suggest to see what s390 does with it. | | Yesterday I added s390* to the list of platforms which need -fPIC in | configure. The problem ought to be solved if I did that in all the needed | places (which I think I did), so can someone try the current 2.3.0 alpha on | s390? I could try and build and upload that later [ as I'm off running now ]. Otherwise, I patches configure and configure.ac with the 'inverted' -ffPIC for all and -ffpic for ppc32 and m68k we had as an alternative. But if -fpic has performance advantages as Drepper claims, I like keeping it the general default. | | We still need evidence of the various claims about -fpic vs -fPIC on s390. | Although I found some evidence of -fPIC being needed in some cases | elsewhere (and even more so on s390x than s390), could not even find the | GOT size. Bastian claimed | | > -fpic is documented to have limitations on some systems and is not | > reliable on some of them for larger software. | | Just where *is* this documented for s390, since it is a gcc flag and it is | not (I am pretty sure) in the gcc documentation (which I have just been | grepping)? Yes, would be nice to hear from Bastian why one global option would be preferred. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361219: patch
On 8 April 2006 at 05:58, Dirk Eddelbuettel wrote: | | On 8 April 2006 at 08:08, Prof Brian D Ripley wrote: | | > So what shall we do? I would be happy to try either one of the two | | > approaches you suggest to see what s390 does with it. | | | | Yesterday I added s390* to the list of platforms which need -fPIC in | | configure. The problem ought to be solved if I did that in all the needed | | places (which I think I did), so can someone try the current 2.3.0 alpha on | | s390? | | I could try and build and upload that later [ as I'm off running now Done, as 2.2.1.svn37668-1. I'll report back when I hear from the autobuilder. My simple upload script caught the rebuild 2.2.1.svn37642-2 first which also got uploaded by mistake. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#361219: patch
On 8 April 2006 at 10:27, Dirk Eddelbuettel wrote: | | On 8 April 2006 at 05:58, Dirk Eddelbuettel wrote: | | | | On 8 April 2006 at 08:08, Prof Brian D Ripley wrote: | | | > So what shall we do? I would be happy to try either one of the two | | | > approaches you suggest to see what s390 does with it. | | | | | | Yesterday I added s390* to the list of platforms which need -fPIC in | | | configure. The problem ought to be solved if I did that in all the needed | | | places (which I think I did), so can someone try the current 2.3.0 alpha on | | | s390? | | | | I could try and build and upload that later [ as I'm off running now | | Done, as 2.2.1.svn37668-1. I'll report back when I hear from the | autobuilder. My simple upload script caught the rebuild 2.2.1.svn37642-2 | first which also got uploaded by mistake. Already built on s390 [ so the bug fix worked ], amd64, alpha, hppa, powerpc, mips and mipsel -- without any failures. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
