Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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 549a6b1: 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 18c4b13: 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 908fcb8: 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 8f19413: 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 72bbce3: 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.
- Loading branch information
