[SciPy-dev] Link problem with scipy on SUN ?

[ERIC JONES]

Hey Arnd,

Short answer:

Sun has only been tested on a single machine, and I hardcoded the libraries
for it to work.  Can you run the following commands on your machine and send
me the output?

        [1]$ f77 -dryrun dummy.f
        ...
        [2]$ f90 -fdryrun dummy.f90

This will help me make a more generic solution.

Longer Answer:

SciPy tries to inspect your machine,learn what Fortran compiler you are
using, and provide the correct libraries and library paths to get everything
to link correctly.

A little background:

The -L directives specify the library directories where the linker (gcc)
should look for needed libraries.  The -l directories specify the libraries
themselves.  -lF77 will look for a file called libF77.a or libF77.so in the
directories you specified with the -L directives, and also a few other
standard locations.

It is a little worrisome that you have -L(null) in some places on the
command line.  I don't think this should happen and it is likely a bug in
build_flib.py.  I'll look into this.  2nd, its strange that the directories
following your -L directives are not full paths.  This can't be right.

The trick you played just kept the linker from looking for the Fortran
libraries (although I'm not quite sure how...), and since vw_wrap doesn't
need them, it will link fine.  However, many of the other modules will need
them, so this is just a temporary fix.

see ya,
eric


----- Original Message -----
From: "Arnd Baecker" <a.backer at bristol.ac.uk>
To: <scipy-dev at scipy.net>
Sent: Sunday, October 21, 2001 4:49 PM
Subject: [SciPy-dev] Link problem with scipy on SUN ?


> Hi,
>
> when trying to install scipy I ran into the following
> link problem under SUN
> (uname -a: SunOS wega 5.8 Generic_108528-07 sun4u sparc
> - I can provide further details if necessary)
>
>
> [...]
> cluster/src/vq_wrap.cpp: In function `int char_to_numtype(char)':
> cluster/src/vq_wrap.cpp:590: warning: control reaches end of non-void
> function `char_to_numtype(char)'
> cluster/src/vq_wrap.cpp: At top level:
> cluster/src/vq_wrap.cpp:516: warning: `struct PyObject *
> l_output_helper(struct PyObject *, struct PyObject *)' defined but not
> used
> gcc -shared build/temp.solaris-2.8-sun4u-2.1/vq_wrap.o -L(null) -LSun/lib
> -L(null) -LSun/lib -Lbuild/temp.solaris-2.8-sun4u-2.1
> -Lbuild/temp.solaris-2.8-sun4u-2.1 -R(null) -RSun/lib -lamos -ltoms
> -lfitpack -lminpack -lquadpack -lodepack -llinpack_lite -lmach -lf90 -lF77
> -lM77 -lsunmath -lm -lgist -lc_misc -lcephes -o
> build/lib.solaris-2.8-sun4u-2.1/scipy/cluster/_vq.so -mimpure-text
> ld: fatal: library -lf90: not found
> ld: fatal: library -lF77: not found
> ld: fatal: library -lM77: not found
> ld: fatal: library -lsunmath: not found
> ld: fatal: File processing errors. No output written to
> build/lib.solaris-2.8-sun4u-2.1/scipy/cluster/_vq.so
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
>
>
> If I replace the above line by
>
> gcc -shared build/temp.solaris-2.8-sun4u-2.1/vq_wrap.o -L(null) -LSun/lib
> -L(null) -LSun/lib -Lbuild/temp.solaris-2.8-sun4u-2.1
> -Lbuild/temp.solaris-2.8-sun4u-2.1 -R(null) -RSun/lib -lamos -ltoms
> -lfitpack -lminpack -lquadpack -lodepack -llinpack_lite -lmach -L -lf90 -L
> -lF77 -L -lM77 -L -lsunmath -lm -lgist -lc_misc -lcephes -o
> build/lib.solaris-2.8-sun4u-2.1/scipy/cluster/_vq.so -mimpure-text
>
> then there is no problem anymore.
> (i.e. adding -L in front of the above libraries does the job ...)
>
> What do I have to change to get rid of this problem ?
> (All the above four libraries seem to be defined in
> the variable self.libraries in build_flib.py.
> but I don't understand enough python yet ... ;-)
>
> Best,
>
> Arnd
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>