Front page | perl.perl5.porters |
Postings from May 2003
> On Mon, May 19, 2003 at 11:43:22PM -0700, Michael G Schwern wrote:
> > On Mon, May 19, 2003 at 11:35:02PM -0700, Michael G Schwern wrote:
> > > Writing Makefile.aperl for Pie
> > > make -f Makefile.aperl perl
> > > Writing perlmain.c
> > > cd . && cc -c "-I/usr/local/perl5.8.0/lib/darwin-64all/CORE" \
> > > -pipe -fno-common -no-cpp-precomp -DDEBUGGING -fno-strict-aliasing -O3 -g \
> > > -DVERSION=\"0.01\" \
> > > -DXS_VERSION=\"0.01\" "-I/usr/local/perl5.8.0/lib/darwin-64all/CORE" perlmain.c
> > > make[1]: *** No rule to make target `/usr/local/perl5.8.0/lib/darwin-64all/CORE/libperl.a', needed by `perl'. Stop.
> > > make: *** [perl] Error 2
> > >
> > > MakeMaker is looking for libperl.a but I have libperl.dylib. MakeMaker
> > > is using $Config{lib_ext} which is .a here. $Config{so} is .dylib.
> > > Which is wrong? Config or MakeMaker?
> > Similar problem on Linux with a Debian built Perl. Do I have to do
> > something special when Perl is built to have Makefile.aperl work?
Hmm. Tricky. If perl is built and configured with -Duseshrplib, then
libperl.a never gets built (at least by default). The actual library
that gets built is available as $Config{libperl}.
Part of the problem is that it's not at all obvious to me what the
ultimate intent here is. This perl was built with -Duseshrplib, but this
particular extension is being "statically linked" in. If MakeMaker is
changed to look for $Config{libperl}, then this extension will be
statically linked into a new binary, but that binary will still use the
libperl.so (or whatever the platform-specific suffix is). Is this the
user's intent? I have no idea. I never imagined this scenario.
Some distributors are apparently going to the extra effort of providing
their users with both libperl.so and libperl.a, but stock perl won't
do that for you.
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next