In response to:
> Message-ID: <20010615180527.B5710@math.ohio-state.edu>
> Date: Fri, 15 Jun 2001 18:05:27 -0400
> From: Ilya Zakharevich <ilya@math.ohio-state.edu>
> To: "Karim.Belabas" <Karim.Belabas@math.u-psud.fr>
> Cc: pari-users list <pari-users@list.cr.yp.to>
> References: <5DDF144C9176D211BE8F00805FC1A0D3051D74A3@duro.lucasfilm.com> <Pine.SOL.3.95.1010615134904.28337A-100000@geo>
>
> On Fri, Jun 15, 2001 at 02:22:31PM +0200, Karim.Belabas wrote:
(...)
> > b) The shared library Pari.so eventually produced is incorrect:
> >
> > ld.so.1: /home/belabas/bin/solaris/perl: elf error:
> > blib/arch/auto/Math/Pari/Pari.so: bad ELF type: ET_NONE at
> > /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169.
>
> Again, I never saw this. Probably a result of your patches? ;-)
Any questions related to Solaris and Sun compiler patchlevels are
best directed to yours truly off-list. ET_NONE means exactly what
it says, something has been generated which has the correct ELF
signature in the first bytes, but then an ELF type of `none', i.e.
not an executable (32 or 64bit) nor a core file... Turn on -V -v
in the compile and link stage flags and record the entire output
of the make run, this should provide a clue what commandline had
been invoked to generate that Pari.so.
> I may use some of your patches. BTW, is -lsunmath needed any more?
If we want to invoke exp2() explicitly, then yes, exp2() is in
libsunmath.so but not in libm.so. Do we need exp2() or can we
work around that? It seems Makefile.PL correctly records the
absence of the library and defines NOEXP2, so this should not
be a problem (if it also suppresses -lsunmath at the link stage).
(See man -s 3m intro for the list of functions in the bundled
Solaris libm and in the unbundled libsunmath.)
(To the gallery - libsunmath.so.1 is not bundled with Solaris,
it comes with the Sun compilers - Forte Developer, formerly known
as Sun WorkShop. Chances are that if you don't have the Sun com-
pilers installed, you won't have libsunmath, unless you received
it redistributed under Sun's runtime libraries licence along with
some other software built with it.)
To Katherine - check which make command you actually invoke when
you type `make' at the root prompt. (which make - would that be
/usr/ccs/bin/make, /usr/xpg4/bin/make, or GNU make installed
somewhere in /usr/local/bin or /opt/gnu/bin or some such place?)
However, it seems something at the configure stage has put a
(mis-spelt?) dependency into the primary makefile. It is looking
for libPARI/Makefile because there's a dependency somewhere which
states that this is required, but it doesn't exist, at least not
under this path name relative to the current working directory
at the time in question. OTOH, it claims to have written a
`Makefile for Math::Pari' a moment earlier. Ilya: that message
came from Makefile.PL, so does that mean that libPARI/Makefile
should have been created at that point? (And the directory
libPARI itself?) I guess make test does want libPARI.a around,
so that part of the dependences looks plausible...
To Katherine again - also check what directory you're in, and
whether it is NFS mounted, and if it is, whether you actually
possess root rights through the NFS mount. If the NFS server
maps you to nobody, you'll probably run into permission problems.
Cheers, Gerhard