Front page | perl.perl5.porters |
Postings from October 2003
Re: 5.8.1: static build completely busted?
Thread Previous
|
Thread Next
From:
Andy Dougherty
Date:
October 9, 2003 13:46
Subject:
Re: 5.8.1: static build completely busted?
Message ID:
Pine.SOL.4.53.0310091613180.19332@maxwell.phys.lafayette.edu
On Tue, 7 Oct 2003, Ilya Zakharevich wrote:
> Yesterday I tried a static build on OS/2, and things turned out to be
> broken in many different ways [for all of which I now know a fix, but
> this is a different story].
Just as a counterpoint, for me, on Solaris, with
sh Configure -Uusedl
it appears to work just fine. All tests pass.
> One of the most pronounced ones is that ./perl is not linked with half
> of the built extensions. Why? Here is the rule of Makefile.SH:
>
> perlmain.c: miniperlmain.c config.sh $(FIRSTMAKEFILE)
> sh writemain $(DYNALOADER) $(static_ext) > writemain.tmp
> sh mv-if-diff writemain.tmp perlmain.c
>
> perl$(EXE_EXT): $& perlmain$(OBJ_EXT) $(LIBPERL) $(DYNALOADER) $(static_ext) ext.libs $(PERLEXPORT)
> -@rm -f miniperl.xok
> $(SHRPENV) $(LDLIBPTH) $(CC) -o perl$(PERL_SUFFIX) $(PERL_PROFILE_LDFLAGS) $(CLDFLAGS) $(CCDLFLAGS) perlmain$(OBJ_EXT) $(DYNALOADER) $(static_ext) $(LLIBPERL) `cat ext.libs` $(libs)
>
> Note that only extensions which are in static_ext are put into
> perlmain.c, and linked into ./perl. However, many (most?) of the
> extensions are actually a subdirectory of another extension; the
> corresponding .a archives *are* build, but are not linked into ./perl
> and perlmain.c.
I don't see this. Here's the command line that eventually gets used to
generate perl for me
cc -o perl -L/usr/local/lib perlmain.o
lib/auto/DynaLoader/DynaLoader.a
lib/auto/B/B.a
lib/auto/ByteLoader/ByteLoader.a
lib/auto/Cwd/Cwd.a
lib/auto/DB_File/DB_File.a
lib/auto/Data/Dumper/Dumper.a
lib/auto/Devel/DProf/DProf.a
lib/auto/Devel/PPPort/PPPort.a
lib/auto/Devel/Peek/Peek.a
lib/auto/Digest/MD5/MD5.a
lib/auto/Encode/Encode.a
lib/auto/Fcntl/Fcntl.a
lib/auto/File/Glob/Glob.a
lib/auto/Filter/Util/Call/Call.a
lib/auto/GDBM_File/GDBM_File.a
lib/auto/I18N/Langinfo/Langinfo.a
lib/auto/IO/IO.a
lib/auto/IPC/SysV/SysV.a
lib/auto/List/Util/Util.a
lib/auto/MIME/Base64/Base64.a
lib/auto/NDBM_File/NDBM_File.a
lib/auto/ODBM_File/ODBM_File.a
lib/auto/Opcode/Opcode.a
lib/auto/POSIX/POSIX.a
lib/auto/PerlIO/encoding/encoding.a
lib/auto/PerlIO/scalar/scalar.a
lib/auto/PerlIO/via/via.a
lib/auto/SDBM_File/SDBM_File.a
lib/auto/Socket/Socket.a
lib/auto/Storable/Storable.a
lib/auto/Sys/Hostname/Hostname.a
lib/auto/Sys/Syslog/Syslog.a
lib/auto/Time/HiRes/HiRes.a
lib/auto/Unicode/Normalize/Normalize.a
lib/auto/attrs/attrs.a
lib/auto/re/re.a
lib/auto/threads/threads.a
lib/auto/threads/shared/shared.a
lib/auto/Encode/Byte/Byte.a
lib/auto/Encode/CN/CN.a
lib/auto/Encode/EBCDIC/EBCDIC.a
lib/auto/Encode/JP/JP.a
lib/auto/Encode/KR/KR.a
lib/auto/Encode/Symbol/Symbol.a
lib/auto/Encode/TW/TW.a
lib/auto/Encode/Unicode/Unicode.a
libperl.a `cat ext.libs` -lsocket -lnsl -lgdbm -ldb -ldl -lm -lc
There is only one missing '.a' file: lib/auto/B/C.a isn't linked in for
some reason. I haven't figured out why. The problems you are
encountering may be specific to extensions not built by default on my
system.
> 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.
> I think the reason for why this mess started is that somebody
> noticed that threads/shared was not linked in, and made this a
> special case - not noticing that a dozen of other extensions is
> not linked too.
I don't know what these other extensions are. I suspect that they too
violate that basic premise. Perhaps that premise needs to be
re-evaluated.
> I tested two solutions:
>
> 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?
> b) Do not use writemain at all (why is it needed?!):
It's probably just historical inertia. writemain predates MakeMaker by
quite a bit.
--
Andy Dougherty doughera@lafayette.edu
Thread Previous
|
Thread Next