develooper Front page | perl.perl5.changes | Postings from October 2021

[Perl/perl5] be1a82: Remove vestigial next4*) sections fromMakefile.SH

Thread Next
From:
Nicholas Clark via perl5-changes
Date:
October 4, 2021 12:32
Subject:
[Perl/perl5] be1a82: Remove vestigial next4*) sections fromMakefile.SH
Message ID:
Perl/perl5/push/refs/heads/smoke-me/nicholas/AIX-Makefile/9ba4b6-a76417@github.com
  Branch: refs/heads/smoke-me/nicholas/AIX-Makefile
  Home:   https://github.com/Perl/perl5
  Commit: be1a8292467bed58a74b8585fa1f3ca9cf0cdcdc
      https://github.com/Perl/perl5/commit/be1a8292467bed58a74b8585fa1f3ca9cf0cdcdc
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-04 (Mon, 04 Oct 2021)

  Changed paths:
    M Cross/Makefile-cross-SH
    M Makefile.SH

  Log Message:
  -----------
  Remove vestigial next4*) sections from Makefile.SH

NeXT support was removed in June 2014 by commit f05550c064c27360:
    Removed NeXT support

but that commit missed these hunks.

The crazy whitespace errors in the next4*) section were added by mistake
by me in June 2013 by commit b78ac7159b42a0e0:
    write_buildcustomize.pl no longer writes to STDOUT

I'm not sure how I goofed that, but it had the side effect of breaking NeXT
builds, and no-one noticed.


  Commit: 847816e65cee9ad88b65ceffcaa5fbb2f298798e
      https://github.com/Perl/perl5/commit/847816e65cee9ad88b65ceffcaa5fbb2f298798e
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-04 (Mon, 04 Oct 2021)

  Changed paths:
    M Makefile.SH

  Log Message:
  -----------
  The AIX specific Makefile rules to build miniperl are no longer needed

The AIX specific Makefile rules to build miniperl are effectively identical
to the default rules for *nix platforms (and have been for some time).

Hence remove the special case logic - the defaults work just fine.


  Commit: 5b587f96555d8465fa5a58672748f7e6d5916965
      https://github.com/Perl/perl5/commit/5b587f96555d8465fa5a58672748f7e6d5916965
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-04 (Mon, 04 Oct 2021)

  Changed paths:
    M Makefile.SH

  Log Message:
  -----------
  The special AIX target MINIPERL_NONSHR is not needed, so remove it

AIX needs to generate a linker definition file prior to linking the perl
binary.

From the dawn of Perl 5, the miniperl binary was built nearly identically to
the perl binary, so for a build using a shared perl library, miniperl was
linked against the shared perl library.

Originally this linker definition file was generated by a shell script, but
this was problematic in various ways, so the AIX build was migrated to share
the Win32 approach - generating the linker definitions using makedef.pl.

Because this needs to be run during the build, and because the build can't
assume that an installed perl binary exists, it needs to be run by a perl
binary in the build tree. (As was) even miniperl needed this file to exist
already, hence when this change was made the Makefile generated for AIX was
changed to add steps to build an extra 'miniperl_nonshr' binary, not using a
shared library, to generate the linker definition file.

This was all done in July 1999 with commit 549a6b102c2ac8c4:
    Fixed AIX dynamic loading and AIX shared Perl library.
    Tested in: AIX 4.1.5 cc+useshrplib+usethreads, 4.1.5 cc,
    4.1.5 gcc+useshrplib+usethreads, 4.3.1 cc+useshrplib.
    Hijacked win32/makedef.pl for more general purpose export
    list building, now it is used (as toplevel makedef.pl)
    for win32 and AIX (perl_exp.SH made unnecessary).
    Because the export lists are now correct in AIX, no more linker
    warnings about "Exported symbol not defined" should appear.

However the need for the 'miniperl_nonshr' binary was actually eliminated in
Feb 2000 by commit 18c4b137c9980e71: fix AIX and multiplicity problems

by the seemingly innocent looking change:

 	case "${osname}${osvers}" in
-	next4*)
+	next4*|aix*)
 		$spitshell >>Makefile <<'!NO!SUBS!'
 miniperl: $& miniperlmain$(OBJ_EXT) $(LIBPERL) opmini$(OBJ_EXT)
 	$(CC) -o miniperl `echo $(obj) | sed 's/ op$(OBJ_EXT) / /'` \

What this does is cause AIX to "join" the NeXTSTEP special case code, that
links miniperl with the object files. Meaning that from this point on AIX
miniperl was never using a shared perl library. So the special case build of
the 'miniperl_nonshr' binary could have been eliminated too.

Independent of this story, miniperl for every other platform *also* stopped
being linked against a shared perl library as of March 2006 with commit
908fcb8bef8cbab8:
    Move DynaLoader.o into libperl.so.

    This avoids the need to statically link DynaLoader into the stub perl
    executable and make libperl.so provide all the code needed to get a
    functional embedded perl interpreter up running.  As a side effect
    this also moves DynaLoader into libperl.a for non-useshrplib builds.

    Fixes [perl #32539]

meaning that AIX no longer needs a special case for shared perl library
builds to keep miniperl unshared, because all platforms have it now.

Finally, in investigating a v5.26.0 build failure, I identified the cause
and then yesterday committed a fix to blead as part of commit 8f1941325681:
    The Makefile must run makedef.pl with -Ilib on the command line

not realising that this had already been identified and fixed by Merijn
in Oct 2017 by commit 72bbce3da5eeffde:
    miniperl also needs -Ilib for perl.exp on AIX etc

My commit mistakenly used miniperl_nonshr again. Revert back to his correct
approach, using the regular miniperl.

And hence we can safely delete miniperl_nonshr and all the logic related to
it, as it has been unused since Oct 2017.


  Commit: 619c007933a923e9b7591540579417a789c26c31
      https://github.com/Perl/perl5/commit/619c007933a923e9b7591540579417a789c26c31
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-04 (Mon, 04 Oct 2021)

  Changed paths:
    M Makefile.SH

  Log Message:
  -----------
  For AIX, modify the perl.exp path in ccdlflags earlier in Makefile.SH

The config.sh value for ccdlflags includes the path to the *installed*
copy of the file perl.exp

While building, that file doesn't exist (or worse, is incompatible) so in
the Makefile we need CCDLFLAGS to point to the local copy. Previously the
Makefile had CCDLFLAGS first set to the value with the installed path, and
then set it again to the local path "for building Perl itself". However,
the Makefile is *only* used for building Perl itself (not installed
extensions), hence we never need the first value. Hence move the sed logic
for the change earlier, write out the first declaration of CCDLFLAGS with
the "local" value, and eliminate the second declaration.

The sed logic was added in July 1999 by commit 5f9d9a1727238445:
    AIX magic: ccdlflags needs to be different for
    Perl itself and for extra-core extensions
    (as used by ExtUtilss::embed::ldopts).
    Based on the problems described in
    To: perl5-porters@perl.org
    Subject: [ID 19990722.002] Perl 5.00503 and AIX 4.1.5; perl.exp; build errors. Also Imagemagick...
    Reply-To: m.w.ellwood@rl.ac.uk
    Message-Id: <Pine.A41.3.96.990722141209.72660V-100000@unixfe.rl.ac.uk>

It probably should have always been done the way this commit now does it.


  Commit: c693b67bacef381d2445137f828bf7bc132fb6ee
      https://github.com/Perl/perl5/commit/c693b67bacef381d2445137f828bf7bc132fb6ee
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-04 (Mon, 04 Oct 2021)

  Changed paths:
    M Makefile.SH

  Log Message:
  -----------
  Simplify Makefile generation for cygwin

The rule to generate cygwin.c with a symbolic link from cygwin/cygwin.c can
actually be written to the generated Makefile on all platforms, as it causes
no problems if not used. It only "triggers" when a cygwin.o is part of the
Makefile macro ARCHOBJS, at which point suffix rules permit make to infer
that cygwin.o can be generated from cygwin.c, and cygwin.c from
cygwin/cygwin.c

The rule to generate LIBPERL_NONSHR is not used. It seems that it was never
used. It was added in July 2008 as part of commit 5f9145a3c5d730d3:
    Cygwin build harmonization, remove cygwin/Makefile.SHs

but the rule added to the top level Makefile.SH doesn't seem to correspond
to any rule in the removed file cygwin/Makefile.SHs


  Commit: a764175f6878a7aed451582b584d99a9486729dc
      https://github.com/Perl/perl5/commit/a764175f6878a7aed451582b584d99a9486729dc
  Author: Nicholas Clark <nick@ccl4.org>
  Date:   2021-10-04 (Mon, 04 Oct 2021)

  Changed paths:
    M Makefile.SH

  Log Message:
  -----------
  Two minor Makefile.SH cleanups

Use "$osname" instead of (bare) $osname in all case statements.
This was the only one that was different.

Delete PATH_SEP, which was never used.
This was added in Nov 1995 as part of commit 4633a7c4bad06b47:
    5.002 beta 1

with various other macros, and the comment "These variables will be used in
a future version to make the make file more portable to non-unix systems."

The other macros have been used, but not PATH_SEP.

Curiously it also gets a different value if one (re)generates Makefile by
running ./Makefile.SH, compared with a Makefile generated by Configure,
because the variable that it is set from - $p_ - is not in config.sh


Compare: https://github.com/Perl/perl5/compare/9ba4b6682c73...a764175f6878

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About