[Debian] link error with neurospin/bindings/linalg.so

[Christopher Burns]

peter green <email address hidden> Sat, Jul 4, 2009 at 7:30 PM
Reply-To: peter green <email address hidden>, <email address hidden>
To: <email address hidden>
I tested this issue in my sid amd64 chroot as user nobody with a nonexistant homedir.

The homedir issue was easy enough to fix but then the build failed with what appeared to be problems caused by lack of a fortran compiler so I added gfortran to the build-dependencies and installed it.

however I then got a load of undefined reference errors (the last couple of which are copied below) and a failure to link

/nobody/nipy-0.1.2+1741/libfffpy/wrapper/fffpy.c:13: undefined reference to `PyE
rr_SetString'
/usr/lib/gcc/x86_64-linux-gnu/4.3.3/libgfortranbegin.a(fmain.o): In function `ma
in':
(.text+0x28): undefined reference to `MAIN__'
collect2: ld returned 1 exit status
error: Command "/usr/bin/gfortran -Wall /nobody/nipy-0.1.2+1741/./build/temp.lin
ux-x86_64-2.5/nipy/neurospin/bindings/linalg.o -L/usr/lib -L/usr/lib -L/nobody/n
ipy-0.1.2+1741/./build/temp.linux-x86_64-2.5 -lfffpy -llapack -lf77blas -lcblas
-latlas -llapack -lf77blas -lcblas -latlas -lgfortran -o /nobody/nipy-0.1.2+1741
/./build/lib.linux-x86_64-2.5/nipy/neurospin/bindings/linalg.so" failed with exi
t status 1
make: *** [debian/python-module-stampdir/python-nipy] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
nobody@debian:/nobody/nipy-0.1.2+1741$

I have attatched a patch with the changes I have made but have no idea how to troubleshoot this link error.

[Alexis Roche (alexis-roche)]

Were the lapack and f77blas libraries built with gfortran? Are you using a site.cfg file? Which python version are you running? Did you try to build scipy on the same environnement?

[Christopher Burns (cburns)]

Hey Alexis,

I've Cc'd Peter Green on this email. He posted the bug on the debian build.

Chris

On Mon, Jul 13, 2009 at 2:52 PM, Alexis Roche<email address hidden> wrote:
> Were the lapack and f77blas libraries built with gfortran? Are you using
> a site.cfg file? Which python version are you running? Did you try to
> build scipy on the same environnement?
>
> --
> [Debian] link error with neurospin/bindings/linalg.so
> https://bugs.launchpad.net/bugs/398937
> You received this bug notification because you are a member of nipy-
> developers, which is the registrant for NIPY.
>
> Status in Neuroimaging in Python: New
>
> Bug description:
> peter green <email address hidden>      Sat, Jul 4, 2009 at 7:30 PM
> Reply-To: peter green <email address hidden>, <email address hidden>
> To: <email address hidden>
> I tested this issue in my sid amd64 chroot as user nobody with a nonexistant homedir.
>
> The homedir issue was easy enough to fix but then the build failed with what appeared to be problems caused by lack of a fortran compiler so I added gfortran to the build-dependencies and installed it.
>
> however I then got a load of undefined reference errors (the last couple of which are copied below) and a failure to link
>
> /nobody/nipy-0.1.2+1741/libfffpy/wrapper/fffpy.c:13: undefined reference to `PyE
> rr_SetString'
> /usr/lib/gcc/x86_64-linux-gnu/4.3.3/libgfortranbegin.a(fmain.o): In function `ma
> in':
> (.text+0x28): undefined reference to `MAIN__'
> collect2: ld returned 1 exit status
> error: Command "/usr/bin/gfortran -Wall /nobody/nipy-0.1.2+1741/./build/temp.lin
> ux-x86_64-2.5/nipy/neurospin/bindings/linalg.o -L/usr/lib -L/usr/lib -L/nobody/n
> ipy-0.1.2+1741/./build/temp.linux-x86_64-2.5 -lfffpy -llapack -lf77blas -lcblas
> -latlas -llapack -lf77blas -lcblas -latlas -lgfortran -o /nobody/nipy-0.1.2+1741
> /./build/lib.linux-x86_64-2.5/nipy/neurospin/bindings/linalg.so" failed with exi
> t status 1
> make: *** [debian/python-module-stampdir/python-nipy] Error 1
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> nobody@debian:/nobody/nipy-0.1.2+1741$
>
> I have attatched a patch with the changes I have made but have no idea how to troubleshoot this link error.
>

--
Christopher Burns
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
510-643-4053
http://cirl.berkeley.edu/

[Matthew Brett (matthew-brett)]

Hi,

> I've Cc'd Peter Green on this email.  He posted the bug on the debian
> build.

Has there been any progress on this?

Matthew

[peter green (plugwash)]

Christopher Burns wrote:
> Hey Alexis,
>
> I've Cc'd Peter Green on this email. He posted the bug on the debian build.
>
Sorry for not responding sooner, I must have missed the mail (I spotted
it while having another poke through the debian rc bugs list)

I'm just doing flyby investigation/fix attempts of rc bugs, I don't
personally know fortran or have any real links with this package,
nevertheless I will do my best to answer your questions.

> Chris
>
> On Mon, Jul 13, 2009 at 2:52 PM, Alexis Roche<email address hidden> wrote:
>
>> Were the lapack and f77blas libraries built with gfortran?
The libraries are from debian packages, they appear to be built with
gfortran but I don't know how to tell for sure
>> Are you using
>> a site.cfg file?
Not that I know of, where would such a file be found
>> Which python version are you running?
2.5 (specifically 2.5.4-2) is the default python version in the
envionment, 2.4 (specifically 2.4.6-2.2) is also pulled in by the
packages build-dependencies which suggests the package is trying to
build against both.
>> Did you try to
>> build scipy on the same environnement?
>>
The build environment had python-scipy 0.7.0-2 installed from the debian
archives
The python-scipy package built from source successfully
Installing the self built python-scipy did not affect the error.

[Gael Varoquaux (gael-varoquaux)]

On Sat, Oct 24, 2009 at 02:10:58AM +0100, peter green wrote:
> Christopher Burns wrote:
>> Hey Alexis,

>> I've Cc'd Peter Green on this email. He posted the bug on the debian build.

> Sorry for not responding sooner, I must have missed the mail (I spotted
> it while having another poke through the debian rc bugs list)

Hey Peter,

I suspect that more recent sources would build easier. I don't know what
the policy would be with regards to pull a more recent version of the
source, but I believe it would be a good thing. We are still not ready to
do a 0.1 release, but getting much closer to it. Maybe having an alpha
version packaged would allow us to realise what difficulties lie in
shipping a robus package under Debian.

Cheers,

Gaël