Package: rpvm
Version: 0.6.2-1
Severity: serious
HI,
rpvm fails to build from source, see attached buildd log.
See section 10.2 of the policy, shared libraries must be
build with -fPIC.
Greetings
Frederik Schueler
--
ENOSIG
From: Source Builder <[email protected]>
To: [email protected], [email protected]
Subject: Log for failed build of rpvm_0.6.2-1 (dist=unstable)
Automatic build of rpvm_0.6.2-1 on athlon.lowpingbastards.de by sbuild/amd64 1.169
Build started at 20040813-1925 ******************************************************************************
Checking available source versions...
Fetching source files...
Reading Package Lists...
Building Dependency Tree...
Need to get 63.4kB of source archives.
Get:1 http://debian-amd64.alioth.debian.org sid/main rpvm 0.6.2-1 (dsc) [596B]
Get:2 http://debian-amd64.alioth.debian.org sid/main rpvm 0.6.2-1 (tar) [61.0kB]
Get:3 http://debian-amd64.alioth.debian.org sid/main rpvm 0.6.2-1 (diff) [1741B]
Fetched 63.4kB in 2s (27.0kB/s)
Download complete and in download only mode
** Using build dependencies supplied by package:
Build-Depends: debhelper (>> 4.1.0), cdbs, r-base-dev (>= 1.9.0), pvm-dev Checking for already installed source dependencies...
debhelper: already installed (in sufficient version 4.2.17 >> 4.1.0)
cdbs: missing
r-base-dev: missing
pvm-dev: missing
Checking for source dependency conflicts...
/usr/bin/sudo /usr/bin/apt-get --purge -q -y install cdbs r-base-dev pvm-dev
Reading Package Lists...
Building Dependency Tree...
The following extra packages will be installed:
atlas3-base f2c g77 g77-3.3 lapack3 lapack3-dev libbz2-1.0 libbz2-dev libg2c0
libg2c0-dev libice6 libjpeg62 libjpeg62-dev libncurses5-dev libpcre3-dev
libpng12-0 libpng12-dev libpvm3 libreadline4 libreadline4-dev libsm6 libx11-6
pvm r-base-core refblas3 refblas3-dev tcl8.4 tk8.4 type-handling
xfree86-common xlibs-data zlib-bin zlib1g-dev
Suggested packages:
fort77 g77-doc g77-3.3-doc bzip2 libpaperg ess r-doc-info r-doc-pdf
r-doc-html r-mathlib r-base-html r-base-latex tclreadline
x-window-system-core x-window-system
Recommended packages:
autotools-dev r-recommended xterm x-terminal-emulator
The following NEW packages will be installed:
atlas3-base cdbs f2c g77 g77-3.3 lapack3 lapack3-dev libbz2-1.0 libbz2-dev
libg2c0 libg2c0-dev libice6 libjpeg62 libjpeg62-dev libncurses5-dev
libpcre3-dev libpng12-0 libpng12-dev libpvm3 libreadline4 libreadline4-dev
libsm6 libx11-6 pvm pvm-dev r-base-core r-base-dev refblas3 refblas3-dev
tcl8.4 tk8.4 type-handling xfree86-common xlibs-data zlib-bin zlib1g-dev Preconfiguring packages ...
0 upgraded, 36 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/28.4MB of archives.
After unpacking 102MB of additional disk space will be used.
Selecting previously deselected package libreadline4.
(Reading database ... 12839 files and directories currently installed.) Unpacking libreadline4 (from .../libreadline4_4.3-11_amd64.deb) ...
Selecting previously deselected package libg2c0.
Unpacking libg2c0 (from .../libg2c0_1%3a3.3.4-7_amd64.deb) ...
Selecting previously deselected package atlas3-base.
Unpacking atlas3-base (from .../atlas3-base_3.6.0-15_amd64.deb) ...
Selecting previously deselected package cdbs.
Unpacking cdbs (from .../archives/cdbs_0.4.22-1_all.deb) ...
Selecting previously deselected package libg2c0-dev.
Unpacking libg2c0-dev (from .../libg2c0-dev_1%3a3.3.4-7_amd64.deb) ... Selecting previously deselected package g77-3.3.
Unpacking g77-3.3 (from .../g77-3.3_1%3a3.3.4-7_amd64.deb) ...
Selecting previously deselected package g77.
Unpacking g77 (from .../g77_4%3a3.3.4-2_amd64.deb) ...
Selecting previously deselected package refblas3.
Unpacking refblas3 (from .../refblas3_1.2-6_amd64.deb) ...
Selecting previously deselected package lapack3.
Unpacking lapack3 (from .../lapack3_3.0.20000531a-4_amd64.deb) ...
Selecting previously deselected package refblas3-dev.
Unpacking refblas3-dev (from .../refblas3-dev_1.2-6_amd64.deb) ...
Selecting previously deselected package lapack3-dev.
Unpacking lapack3-dev (from .../lapack3-dev_3.0.20000531a-4_amd64.deb) ... Selecting previously deselected package libbz2-1.0.
Unpacking libbz2-1.0 (from .../libbz2-1.0_1.0.2-1_amd64.deb) ...
Selecting previously deselected package libbz2-dev.
Unpacking libbz2-dev (from .../libbz2-dev_1.0.2-1_amd64.deb) ...
Selecting previously deselected package libice6.
Unpacking libice6 (from .../libice6_4.3.0.dfsg.1-6_amd64.deb) ...
Selecting previously deselected package libjpeg62.
Unpacking libjpeg62 (from .../libjpeg62_6b-9_amd64.deb) ...
Selecting previously deselected package libjpeg62-dev.
Unpacking libjpeg62-dev (from .../libjpeg62-dev_6b-9_amd64.deb) ...
Selecting previously deselected package libncurses5-dev.
Unpacking libncurses5-dev (from .../libncurses5-dev_5.4-4_amd64.deb) ... Selecting previously deselected package libpcre3-dev.
Unpacking libpcre3-dev (from .../libpcre3-dev_4.5-1.1_amd64.deb) ... Selecting previously deselected package libpng12-0.
Unpacking libpng12-0 (from .../libpng12-0_1.2.5.0-7_amd64.deb) ...
Selecting previously deselected package zlib1g-dev.
Unpacking zlib1g-dev (from .../zlib1g-dev_1%3a1.2.1.1-5_amd64.deb) ... Selecting previously deselected package libpng12-dev.
Unpacking libpng12-dev (from .../libpng12-dev_1.2.5.0-7_amd64.deb) ... Selecting previously deselected package libreadline4-dev.
Unpacking libreadline4-dev (from .../libreadline4-dev_4.3-11_amd64.deb) ... Selecting previously deselected package libsm6.
Unpacking libsm6 (from .../libsm6_4.3.0.dfsg.1-6_amd64.deb) ...
Selecting previously deselected package xfree86-common.
I got another one which was similar from the m68k crowd, I think the pvm package may have something to do with this.
gcc -shared -o rpvm.so rpvm_core.o rpvm_ser.o utils.o -lpvm3 -lgpvm3 -lreadline -lncurses -L/usr/lib/R/bin -lR
/usr/bin/ld: /usr/lib/gcc-lib/x86_64-linux/3.3.4/../../../../lib64/libgpvm3.a(pvmgsu_core.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc-lib/x86_64-linux/3.3.4/../../../../lib64/libgpvm3.a: could not read symbols: Bad value
unmerge 264403
reassign 264403 pvm
severity 265597 important
thanks
On Sun, Aug 15, 2004 at 09:11:56PM -0500, Dirk Eddelbuettel wrote:
I got another one which was similar from the m68k crowd, I think the pvm package may have something to do with this.
These are definitely separate issues. One is about pvmgetarch returning bogus values on a released architechture (m68k), the other one is about lack of -fPIC on a non-released architechture (amd64). The former seems like a pvm bug to me -- I'm less sure about the latter ATM.
gcc -shared -o rpvm.so rpvm_core.o rpvm_ser.o utils.o -lpvm3 -lgpvm3 -lreadline -lncurses -L/usr/lib/R/bin -lR
/usr/bin/ld: /usr/lib/gcc-lib/x86_64-linux/3.3.4/../../../../lib64/libgpvm3.a(pvmgsu_core.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc-lib/x86_64-linux/3.3.4/../../../../lib64/libgpvm3.a: could not read symbols: Bad value
"libgpvm3.a" should give a hint -- pvm simply never builds a shared library version of libgpvm3:
trofast:~/pvm-3.4.2# dpkg -L libpvm3 pvm-dev | grep gpvm
/usr/lib/libgpvm3.a
Having a shared library for libpvm3 itself is a Debian extension (upstream gives a static library only), so I'm a bit unsure if trying to make a shared rpvm.so makes sense at all given upstream (I assume this package isn't Debian-specific). Any thoughts?
On Mon, Aug 16, 2004 at 11:55:22PM +0200, Steinar H. Gunderson wrote:
unmerge 264403
reassign 264403 pvm
severity 265597 important
thanks
On Sun, Aug 15, 2004 at 09:11:56PM -0500, Dirk Eddelbuettel wrote:
I got another one which was similar from the m68k crowd, I think the pvm package may have something to do with this.
These are definitely separate issues. One is about pvmgetarch returning bogus
values on a released architechture (m68k), the other one is about lack of -fPIC on a non-released architechture (amd64). The former seems like a pvm bug to me -- I'm less sure about the latter ATM.
Ack.
gcc -shared -o rpvm.so rpvm_core.o rpvm_ser.o utils.o -lpvm3 -lgpvm3 -lreadline -lncurses -L/usr/lib/R/bin -lR
/usr/bin/ld: /usr/lib/gcc-lib/x86_64-linux/3.3.4/../../../../lib64/libgpvm3.a(pvmgsu_core.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc-lib/x86_64-linux/3.3.4/../../../../lib64/libgpvm3.a: could not read symbols: Bad value
"libgpvm3.a" should give a hint -- pvm simply never builds a shared library version of libgpvm3:
trofast:~/pvm-3.4.2# dpkg -L libpvm3 pvm-dev | grep gpvm /usr/lib/libgpvm3.a
Having a shared library for libpvm3 itself is a Debian extension (upstream gives a static library only), so I'm a bit unsure if trying to make a shared
rpvm.so makes sense at all given upstream (I assume this package isn't Debian-specific). Any thoughts?
I don't follow.
R is an extensible system. Over 400 packages for R are available at cran.r-project.org, and www.bioconductor.org. Maybe 1/3 to 1/2 of these involve compiled code that gets linked into .so libraries and loaded into R when the corresponding package is loaded at run-time using R's library() function.
In other words, hundreds of other packages use .so libraries to extend R dynamically. This often involves external libraries -- consider e.g. the
rmpi package, or many others.
If there is a problem, it may have to do with something special on either amd64, or the interaction of pvm and the rpvm (upstream) package. R itself uses a standard 'configure; make; make install' system hidden inside its 'R CMD INSTALL foo' system.
How do you suggest we proceed from here?
Cheers, Dirk
--
Those are my principles, and if you don't like them... well, I have others.
-- Groucho Marx
Sorry, re-reading this I think I understand now what you meant. Do you suggest that because upstream cannot assume pvm to be present as a shared library, it may get confused when it finds one?
Rpvm seems to have built on at least one system (arm) so that would be a counter-example to the 'it cannot work' claim.
On Mon, Aug 16, 2004 at 05:33:17PM -0500, Dirk Eddelbuettel wrote:
Sorry, re-reading this I think I understand now what you meant. Do you suggest that because upstream cannot assume pvm to be present as a shared library, it may get confused when it finds one?
Correct. It seems that the configure script finds libpvm3.so and assumes that it can build a shared library, without ever checking for libgpvm3.so.
Rpvm seems to have built on at least one system (arm) so that would be a counter-example to the 'it cannot work' claim.
"Works by accident" is not a counter-example to "it makes no sense and will probably break". AFAICS there are two possible solutions:
1. Fix rpvm to understand that "libpvm3.so exists" does not imply that
"libgpvm3.so exists" (ie. don't build shared libraries unless both are
present).
2. Make the pvm package build a shared libgpvm3.so -- I'm rather reluctant to
do this pre-sarge (you never know what breaks), and #1 should be done
anyhow...
1. Fix rpvm to understand that "libpvm3.so exists" does not imply thatHm. Remind me again why we have one but not the other?
"libgpvm3.so exists" (ie. don't build shared libraries unless both are
present).
2. Make the pvm package build a shared libgpvm3.so -- I'm rather reluctant toLet's it in experimental then.
do this pre-sarge (you never know what breaks), and #1 should be done
anyhow...
On Mon, Aug 16, 2004 at 08:37:06PM -0500, Dirk Eddelbuettel wrote:
1. Fix rpvm to understand that "libpvm3.so exists" does not imply thatHm. Remind me again why we have one but not the other?
"libgpvm3.so exists" (ie. don't build shared libraries unless both are >> present).
Historical reasons, nothing else. I guess the previous maintainer forgot to add a shared library for libgpvm when he added libpvm.
2. Make the pvm package build a shared libgpvm3.so -- I'm rather reluctant toLet's it in experimental then.
do this pre-sarge (you never know what breaks), and #1 should be done >> anyhow...
Yeah, I can make the change in experimental. rpvm should still be fixed, though.
Historical reasons, nothing else. I guess the previous maintainer forgot to >> add a shared library for libgpvm when he added libpvm.I'm still confused: where is libgpvm from? Which package?
Hm. Let me play devil's advocate for a minute -- Why does it need a fix when it works in i386?
Looking at configure.in (included below) from rpvm, I am starting to agree. It does look rather explicitly at the .a and we may need to make that more general and allow for the .so as well.
OTOH it just works for me (see partial build log below) -- i.e. even though it looks for .a, what it sets are the -L flags and the linker then uses the .so anyway.
AC_CHECK_LIB(pvm3,main,PVM_LIBS="",
[ echo "Try to find libpvm3 ..."
if test -f /usr/local/lib/libpvm3.a; then
echo "Found in /usr/local/lib"
PVM_LIBS="-L/usr/local/lib"
elif test -f ${PVM_ROOT}/lib/${PVM_ARCH}/libpvm3.a; then
echo "Found in ${PVM_ROOT}/lib/${PVM_ARCH}"
PVM_LIBS="-L${PVM_ROOT}/lib/${PVM_ARCH}"
AC_CHECK_LIB(gpvm3,main,PVM_LIBS="",
[ echo "Try to find libgpvm3 ..."
if test -f /usr/local/lib/libgpvm3.a; then
echo "Found in /usr/local/lib"
PVM_LIBS="-L/usr/local/lib"
elif test -f ${PVM_ROOT}/lib/${PVM_ARCH}/libgpvm3.a; then
echo "Found in ${PVM_ROOT}/lib/${PVM_ARCH}"
PVM_LIBS="-L${PVM_ROOT}/lib/${PVM_ARCH}"
else
echo "Cannot find libgpvm3"
exit 1
fi ]
)
Why? Isn't that exactly what 'gcc -o hello_world hello.c' does? UsesOTOH it just works for me (see partial build log below) -- i.e. even though >>> it looks for .a, what it sets are the -L flags and the linker then uses the >>> .so anyway.That sounds broken.
default libraries from default locations, preference to .so. -L directs to non-standard lib dirs. All very standard, and time-honoured.
I don't buy the brokenness argument as the right values seem to pop out anyway where I can test. If amd64 needs something else, then we may test
for it it alone. Same with the quasi-permanently broken m68k nightmare.
[...]
So other than aiming for the higher moral ground, which is fine in and by itself, how do we put this back onto a constructive track?
On Tue, Aug 17, 2004 at 04:59:53PM -0500, Dirk Eddelbuettel wrote:
Historical reasons, nothing else. I guess the previous maintainer forgot toI'm still confused: where is libgpvm from? Which package?
add a shared library for libgpvm when he added libpvm.
Source package pvm, just like libpvm. The static library (libgpvm3.a) is of course in the pvm-dev binary package.
Hm. Let me play devil's advocate for a minute -- Why does it need a fix when
it works in i386?
Because it obviously breaks on other archs? :-) Newer binutils on i386 don't need -fPIC to build code that will be used in shared libraries; other architectures (like obviously amd64) do.
Looking at configure.in (included below) from rpvm, I am starting to agree. It does look rather explicitly at the .a and we may need to make that more general and allow for the .so as well.
Uhm, now I'm a bit confused... My understanding of the correct configure behavior is:
- Check for libpvm3.so.
- Check for libgpvm3.so.
- If both of these exist, build a shared library. If not, give it up (and
build a static one if applicable -- I don't know R, so I don't know if this
can be done at all for R extensions).
OTOH it just works for me (see partial build log below) -- i.e. even though it looks for .a, what it sets are the -L flags and the linker then uses the .so anyway.
That sounds broken.
AC_CHECK_LIB(pvm3,main,PVM_LIBS="",
[ echo "Try to find libpvm3 ..."
if test -f /usr/local/lib/libpvm3.a; then
echo "Found in /usr/local/lib"
PVM_LIBS="-L/usr/local/lib"
Whoa...
elif test -f ${PVM_ROOT}/lib/${PVM_ARCH}/libpvm3.a; then
echo "Found in ${PVM_ROOT}/lib/${PVM_ARCH}"
PVM_LIBS="-L${PVM_ROOT}/lib/${PVM_ARCH}"
More whoa. It should definitely check for .so if it plans to link shared. This entire manual checking looks like a bad hack to me...
AC_CHECK_LIB(gpvm3,main,PVM_LIBS="",
[ echo "Try to find libgpvm3 ..."
if test -f /usr/local/lib/libgpvm3.a; then
echo "Found in /usr/local/lib"
PVM_LIBS="-L/usr/local/lib"
elif test -f ${PVM_ROOT}/lib/${PVM_ARCH}/libgpvm3.a; then
echo "Found in ${PVM_ROOT}/lib/${PVM_ARCH}"
PVM_LIBS="-L${PVM_ROOT}/lib/${PVM_ARCH}"
else
echo "Cannot find libgpvm3"
exit 1
fi ]
)
Same here.
/* Steinar */
--
Homepage: http://www.sesse.net/
On Tue, Aug 17, 2004 at 05:23:53PM -0500, Dirk Eddelbuettel wrote:
Why? Isn't that exactly what 'gcc -o hello_world hello.c' does? Uses default libraries from default locations, preference to .so. -L directs to non-standard lib dirs. All very standard, and time-honoured.OTOH it just works for me (see partial build log below) -- i.e. even thoughThat sounds broken.
it looks for .a, what it sets are the -L flags and the linker then uses the
.so anyway.
The problem is that in this case, the static library _cannot_ be used
(except in the few cases where it actually works by accident, like i386). For hello world, it doesn't matter; for a shared library, it seems to do.
I don't buy the brokenness argument as the right values seem to pop out anyway where I can test. If amd64 needs something else, then we may test for it it alone. Same with the quasi-permanently broken m68k nightmare.
[...]
So other than aiming for the higher moral ground, which is fine in and by itself, how do we put this back onto a constructive track?
Well, the best hack is probably to enable a shared libgpvm, but like I said, I'd prefer to keep that out of sarge. In addition, rpvm should be changed to simply check for .so instead of .a, which makes the breakage easier to spot when it's there (ie. a PVM built without shared libraries).
On Tue, Aug 17, 2004 at 05:37:04PM -0500, Dirk Eddelbuettel wrote:
The problem is that in this case, the static library _cannot_ be usedCould we try to demonstrate that it actually _is_ broken? So far we seem
(except in the few cases where it actually works by accident, like i386). For
hello world, it doesn't matter; for a shared library, it seems to do.
to concentrate on 'may', 'could', 'seems' or 'should'. Little vague, no? ;-)
On some platforms, _all_ code in a shared library _must_ be compiled with -fPIC. Static libraries aren't compiled with -fPIC. Clear enough? :-)
I resist pushing this upstream just for pure Debian stubbornness. Arguably, the error is with the .a / .so mix in our pvm package.
No, it is not; it will break with two .a files as well.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 42:00:31 |
| Calls: | 12,109 |
| Files: | 15,006 |
| Messages: | 6,518,416 |