[p5sagit/p5-mst-13.2.git] / hints / next_3.sh

# This file has been put together by Anno Siegel <siegel@zrz.TU-Berlin.DE>,
# Andreas Koenig <k@franz.ww.TU-Berlin.DE> and Gerd Knops <gerti@BITart.com>.
# Comments, questions, and improvements welcome!
#
# These hints work for NeXT 3.2 and 3.3.  3.0 has it's own
# special hint file.
#

ccflags='-DUSE_NEXT_CTYPE -DUSE_PERL_SBRK -DHIDEMYMALLOC'
POSIX_cflags='ccflags="-posix $ccflags"'
ldflags='-u libsys_s'
libswanted='dbm gdbm db'

lddlflags='-nostdlib -r'
# Give cccdlflags an empty value since Configure will detect we are
# using GNU cc and try to specify -fpic for cccdlflags.
cccdlflags=' '

#
# Change the line below if you do not want to build 'quad-fat'
# binaries
#
mab='-arch m68k -arch i386 -arch hppa -arch sparc'

archname='next-fat'
ld='cc'

i_utime='undef'
groupstype='int'
direntrytype='struct direct'
d_strcoll='undef'

######################################################################
# THE MALLOC STORY
######################################################################
# 1994:
# the simple program `for ($i=1;$i<38771;$i++){$t{$i}=123}' fails
# with Larry's malloc on NS 3.2 due to broken sbrk()
#
# setting usemymalloc='n' was the solution back then. Later came
# reports that perl would run unstable on 3.2:
#
# From about perl5.002beta1h perl became unstable on the
# NeXT. Intermittent coredumps were frequent on 3.2 OS. There were
# reports, that the developer version of 3.3 didn't have problems, so it
# seemed pretty obvious that we had to work around an malloc bug in 3.2.
# This hints file reflects a patch to perl5.002_01 that introduces a
# home made sbrk routine (remember, NeXT's sbrk _never_ worked). This
# sbrk makes it possible to run perl with its own malloc. Thanks to
# Ilya who showed me the way to his sbrk for OS/2!!
# andreas koenig, 1996-06-16
#
# So, this hintsfile is using perl's malloc. If you want to turn perl's
# malloc off, you need to change remove '-DUSE_PERL_SBRK' and 
# '-DHIDEMYMALLOC' from the ccflags above and set usemymalloc below
# to 'n'.
#
######################################################################
usemymalloc='y'

d_uname='define'
d_setpgid='define'
d_setsid='define'
d_tcgetpgrp='define'
d_tcsetpgrp='define'

#
# On some NeXT machines, the timestamp put by ranlib is not correct, and
# this may cause useless recompiles.  Fix that by adding a sleep before
# running ranlib.  The '5' is an empirical number that's "long enough."
#
ranlib='sleep 5; /bin/ranlib' 

#
# There where reports that the compiler on HPPA machines
# fails with the -O flag on pp.c.
pp_cflags='optimize="-g"'
Commit	Line	Data
760ac839	1	# This file has been put together by Anno Siegel <siegel@zrz.TU-Berlin.DE>,
	2	# Andreas Koenig <k@franz.ww.TU-Berlin.DE> and Gerd Knops <gerti@BITart.com>.
	3	# Comments, questions, and improvements welcome!
4aa0a1f7	4	#
	5	# These hints work for NeXT 3.2 and 3.3. 3.0 has it's own
	6	# special hint file.
760ac839	7	#
4aa0a1f7	8
760ac839	9	ccflags='-DUSE_NEXT_CTYPE -DUSE_PERL_SBRK -DHIDEMYMALLOC'
75f92628	10	POSIX_cflags='ccflags="-posix $ccflags"'
85e6fe83	11	ldflags='-u libsys_s'
a0d0e21e	12	libswanted='dbm gdbm db'
5d94fbed	13
61d11634	14	lddlflags='-nostdlib -r'
5d94fbed	15	# Give cccdlflags an empty value since Configure will detect we are
	16	# using GNU cc and try to specify -fpic for cccdlflags.
	17	cccdlflags=' '
	18
760ac839	19	#
	20	# Change the line below if you do not want to build 'quad-fat'
	21	# binaries
	22	#
61d11634	23	mab='-arch m68k -arch i386 -arch hppa -arch sparc'
760ac839	24
61d11634	25	archname='next-fat'
	26	ld='cc'
	27
a0d0e21e	28	i_utime='undef'
	29	groupstype='int'
	30	direntrytype='struct direct'
	31	d_strcoll='undef'
760ac839	32
	33	######################################################################
	34	# THE MALLOC STORY
	35	######################################################################
	36	# 1994:
a0d0e21e	37	# the simple program `for ($i=1;$i<38771;$i++){$t{$i}=123}' fails
a0d0e21e	38	# with Larry's malloc on NS 3.2 due to broken sbrk()
760ac839	39	#
	40	# setting usemymalloc='n' was the solution back then. Later came
	41	# reports that perl would run unstable on 3.2:
	42	#
	43	# From about perl5.002beta1h perl became unstable on the
	44	# NeXT. Intermittent coredumps were frequent on 3.2 OS. There were
	45	# reports, that the developer version of 3.3 didn't have problems, so it
	46	# seemed pretty obvious that we had to work around an malloc bug in 3.2.
	47	# This hints file reflects a patch to perl5.002_01 that introduces a
	48	# home made sbrk routine (remember, NeXT's sbrk _never_ worked). This
	49	# sbrk makes it possible to run perl with its own malloc. Thanks to
	50	# Ilya who showed me the way to his sbrk for OS/2!!
	51	# andreas koenig, 1996-06-16
	52	#
	53	# So, this hintsfile is using perl's malloc. If you want to turn perl's
	54	# malloc off, you need to change remove '-DUSE_PERL_SBRK' and
	55	# '-DHIDEMYMALLOC' from the ccflags above and set usemymalloc below
	56	# to 'n'.
	57	#
	58	######################################################################
	59	usemymalloc='y'
	60
a0d0e21e	61	d_uname='define'
	62	d_setpgid='define'
	63	d_setsid='define'
	64	d_tcgetpgrp='define'
	65	d_tcsetpgrp='define'
760ac839	66
ecfc5424	67	#
	68	# On some NeXT machines, the timestamp put by ranlib is not correct, and
	69	# this may cause useless recompiles. Fix that by adding a sleep before
	70	# running ranlib. The '5' is an empirical number that's "long enough."
760ac839	71	#
ecfc5424	72	ranlib='sleep 5; /bin/ranlib'
760ac839	73
40000a8c	74	#
	75	# There where reports that the compiler on HPPA machines
	76	# fails with the -O flag on pp.c.
40000a8c	77	pp_cflags='optimize="-g"'