Not OK: perl 5.00563 on OPENSTEP-Mach 4_2 (UNINSTALLED)

[p5pRT]

Migrated from rt.perl.org#1904 (status was 'resolved')

Searchable as RT1904$

[p5pRT]

From hansmu@xs4all.nl

_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​: $&amp; 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​: $&amp; 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​: $&amp; 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

[p5pRT]

From @gsar

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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