develooper Front page | perl.perl5.porters | Postings from October 2003

Re: 5.8.1: static build completely busted?

Thread Previous | Thread Next
Ilya Zakharevich
October 9, 2003 21:02
Re: 5.8.1: static build completely busted?
Message ID:
On Thu, Oct 09, 2003 at 04:46:18PM -0400, Andy Dougherty wrote:
> There is only one missing '.a' file:  lib/auto/B/C.a isn't linked in for
> some reason.

See my initial message for the reason.

> > Aside: remember the mess generated by having both threads and
> >        threads/shared in static_ext?  And the resulting mess of having
> >        NORECURS=1 in ext/threads/Makefile.PL?  [And many other
> >        resulting messes - e.g., static OS/2 build being broken by this
> >        NORECURS. ;-(  ;-)]
> Yes, threads/shared violates a basic premise of the ext/ directory, namely
> that ext/Foo/Makefile.PL handles everything under ext/Foo.  (This
> convention was to allow users to stick arbitrary extensions under ext/ and
> have them 'just work' without Configure having to understand the inner
> workings of the extension.)  Another extension that violates this rule is
> Encode.  I complained about that, but was overruled, and hence Encode is
> special-cased in Configure.

Just change two lines I marked in Makefile, and one can remove these
special cases from Configure.  With my configuration, the only files
which are not picked up are B::C, Encode::*, and threads::shared.  And
you observed this already: the first library is not picked up, the
rest need special-casing in Configure.  [And since you have both
Encode and Encode/JP in your static_ext, you cannot reliably `make -j
4' too in the current configuration.]

> > a) put $(static_ext) as a dependence of perlmain.c; then replace
> >    $(static_ext) by `cat extlist` with
> >
> >    # Assume that extensions are at most 4 deep (this is so with 5.8.1)
> >    aout_extlist: $(aout_static_ext)
> > 	      echo lib/auto/*.a lib/auto/*/*.a lib/auto/*/*/*.a lib/auto/*/*/*/*.a | tr ' ' '\n' | grep -v '\*' > $@.tmp
> > 	      sh mv-if-diff $@.tmp $@

> I don't see any immediate problem with this, since the lists generated in
> my case are identical (except for B/C.a).  However, what about after perl
> is installed and you want to build a new perl?  Where will MakeMaker get
> the approrpriate list of libraries?

Makemaker builds this list itself: the *.a files are installed,
makemaker scans for them, and builds the list of things to link.  This
is why my recipe in "b" works (one which uses `make perl' in a
subdirectory via MakeMaker).

Hope this helps,

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About