Closed p5pRT closed 20 years ago
_63 fails to build on NeXTstep. The biggest problem is that miniperl fails to run. Miniperl is created by linking miniperlmain.o and miniop.o against the perl dynamic library. This library contains op.o\, which defines the same symbols as miniop.o\, becuase both files are created by compiling op.c (with different settings of the EXTERNAL_GLOB flag). This leads to dozens of warnings when miniperl is linked and a fatal runtime error: "multiple definitions of symbol _Perl_listkids".
The patch below works around the problem by not using libperl when creating miniperl. Instead it links all the .o files that make up libperl (except op.o\, of course).
-- HansM
*** Makefile.SH.orig Wed Dec 8 07:23:10 1999
--- Makefile.SH Wed Dec 15 20:52:19 1999
***************
*** 421\,431 ****
--- 421\,450 ----
# build problems but that's not obvious to the novice.
# The Module used here must not depend on Config or any extensions.
+ !NO!SUBS!
+
+ case "${osname}${osvers}" in
+ next4*)
+ $spitshell >>Makefile \<\<'!NO!SUBS!'
+ miniperl: $& miniperlmain$(OBJ_EXT) $(LIBPERL)
+ $(CCCMD) $(PLDLFLAGS) -DPERL_EXTERNAL_GLOB -o opmini$(OBJ_EXT) op.c
+ $(CC) -o miniperl `echo $(obj) | sed 's/ op$(OBJ_EXT) / /'` \
+ miniperlmain$(OBJ_EXT) opmini$(OBJ_EXT) perl$(OBJ_EXT) $(libs)
+ $(LDLIBPTH) ./miniperl -w -Ilib -MExporter -e 0 || $(MAKE) minitest
+ !NO!SUBS!
+ ;;
+ *)
+ $spitshell >>Makefile \<\<'!NO!SUBS!'
miniperl: $& miniperlmain$(OBJ_EXT) $(LIBPERL)
$(CCCMD) $(PLDLFLAGS) -DPERL_EXTERNAL_GLOB -o opmini$(OBJ_EXT) op.c
$(LDLIBPTH) $(CC) $(LARGE) $(CLDFLAGS) -o miniperl \
miniperlmain$(OBJ_EXT) opmini$(OBJ_EXT) $(LLIBPERL) $(libs)
$(LDLIBPTH) ./miniperl -w -Ilib -MExporter -e 0 || $(MAKE) minitest
+ !NO!SUBS!
+ ;;
+ esac
+
+ $spitshell >>Makefile \<\<'!NO!SUBS!'
perl: $& perlmain$(OBJ_EXT) $(LIBPERL) $(DYNALOADER) $(static_ext) ext.libs $(PERLEXPORT)
$(SHRPENV) $(LDLIBPTH) $(CC) $(LARGE) $(CLDFLAGS) $(CCDLFLAGS) -o perl perlmain$(OBJ_EXT) $(DYNALOADER) $(static_ext) $(LLIBPERL) `cat ext.libs` $(libs)
Site configuration information for perl 5.00563:
Configured by hansm at Mon Dec 13 02:03:09 MET 1999.
Summary of my perl5 (revision 5.0 version 5 subversion 63) configuration: Platform: osname=next\, osvers=4_2\, archname=OPENSTEP-Mach uname='bombadil ' config_args='-des -Dcf_email=hansmu@xs4all.nl -Dprefix=/usr/local -Doptimize=-g -O' hint=recommended\, useposix=undef\, d_sigaction=undef usethreads=undef useperlio=undef d_sfio=undef use64bits=undef usemultiplicity=undef Compiler: cc='cc'\, optimize='-g -O'\, gccversion=NeXT DevKit-based CPP 4.0 cppflags='-dynamic -fno-common -DUSE_NEXT_CTYPE -DUSE_PERL_SBRK -arch m68k -DDEBUGGING -I/usr/local/include' ccflags ='-dynamic -fno-common -DUSE_NEXT_CTYPE -DUSE_PERL_SBRK -arch m68k -arch i386 -DDEBUGGING -I/usr/local/include' stdchar='char'\, d_stdstdio=define\, usevfork=false intsize=4\, longsize=4\, ptrsize=4\, doublesize=8 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 alignbytes=8\, usemymalloc=y\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -dynamic -prebind -arch m68k -arch i386 -L/usr/local/lib' libpth=/lib /usr/lib /usr/local/lib libs= libc=/NextLibrary/Frameworks/System.framework/System\, so=dylib\, useshrplib=true\, libperl=libperl.5.dylib Dynamic Linking: dlsrc=dl_next.xs\, dlext=bundle\, d_dlsymun=undef\, ccdlflags=' ' cccdlflags=' '\, lddlflags=' -dynamic -bundle -undefined suppress -arch m68k -arch i386 -L/usr/local/lib'
Locally applied patches:
@INC for perl 5.00563: lib /Users/hansm/lib/perl /usr/local/lib/perl5/5.00563/OPENSTEP-Mach /usr/local/lib/perl5/5.00563 /usr/local/lib/site_perl/5.00563/OPENSTEP-Mach /usr/local/lib/site_perl .
Environment for perl 5.00563: DYLD_LIBRARY_PATH=/Users/hansm/src/perl/build/perl-5.006/perl5.005_63:/Users/hansm/src/perl/build/perl-5.006/perl5.005_63 HOME=/Users/hansm LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/Users/hansm/bin:/usr/local/bin:/usr/games:/usr/ucb:/bin:/usr/bin:/usr/etc:/Users/hansm/bin/cookies:/LocalApps/Opener.app:. PERL5LIB=/Users/hansm/lib/perl PERL_BADLANG (unset) SHELL=/bin/sh
On Thu\, 16 Dec 1999 00:29:58 +0100\, Hans Mulder wrote:
_63 fails to build on NeXTstep. The biggest problem is that miniperl fails to run. Miniperl is created by linking miniperlmain.o and miniop.o against the perl dynamic library. This library contains op.o\, which defines the same symbols as miniop.o\, becuase both files are created by compiling op.c (with different settings of the EXTERNAL_GLOB flag). This leads to dozens of warnings when miniperl is linked and a fatal runtime error: "multiple definitions of symbol _Perl_listkids".
I _thought_ someos wasn't going to like that...
When I was adding that\, I had half a mind to make a libminiperl.a out of opmini.o and use that in front of libperl.a. Will doing that fix it as well?
The patch below works around the problem by not using libperl when creating miniperl. Instead it links all the .o files that make up libperl (except op.o\, of course).
Thanks. IIRC\, there were two such locations that need patching.
Sarathy gsar@ActiveState.com
Gurusamy Sarathy wrote:
When I was adding that\, I had half a mind to make a libminiperl.a out of opmini.o and use that in front of libperl.a. Will doing that fix it as well?
No it wouldn't: you'd still have duplicate symbols.
A clean approach would be to not include op.o in libperl initially and add it after miniperl has completed its mission. This assumes that we can add .o files to an existing library. The "r" command in ar(1) does that; newer library-building tools do not appear to have a similar option. Of course we can always delete libperl and rebuild it from scratch.
Or we could create a libminiperl.a containing everything except op.o. But then we would use that library exactly once (to build miniperl)\, so we could just as well skip the library-creation and link miniperl directly from the .o files.
The patch below works around the problem by not using libperl when creating miniperl. Instead it links all the .o files that make up libperl (except op.o\, of course).
IIRC\, there were two such locations that need patching.
I only had to make this one change to build miniperl.
-- HansM
Hans Mulder writes:
Gurusamy Sarathy wrote:
When I was adding that\, I had half a mind to make a libminiperl.a out of opmini.o and use that in front of libperl.a. Will doing that fix it as well?
No it wouldn't: you'd still have duplicate symbols.
A clean approach would be to not include op.o in libperl initially and add it after miniperl has completed its mission.
Will not work for those who change things and recompile.
This assumes that we can add .o files to an existing library.
No need for this. Unlinking is enough. ;-)
Ilya
Migrated from rt.perl.org#1904 (status was 'resolved')
Searchable as RT1904$