HP-UX build notes
Nick Glencross
on other platforms.
The system in question is a PA-RISC HP-UX 11.11 system
(hppa2.0w-hp-hpux11.11). The system only has the bundled C compiler and
linker, so I've compiled gcc 3.3.6 for it. gcc cannot create debug
information without gas, which is unfortunately not supported on this
platform.
I also built Perl from source:
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
In Parrot's config.h I've got:
#define INTVAL_SIZE 4
#define NUMVAL_SIZE 8
#define OPCODE_T_SIZE 4
#define PTR_SIZE 4
#define SHORT_SIZE 2
#define INT_SIZE 4
#define LONG_SIZE 4
#define HUGEINTVAL_SIZE 8
#define DOUBLE_SIZE 8
Here are a few niggles:
* *Lots* of this warning in the ops:
ops/experimental.ops:285: warning: cast increases required
alignment of target type
* ld keeps being run with -g which is not a valid flag
* A warning is generated from cpp about the line in config.h as it
contains a slash.
#define PARROT_9000/800 1
* Had trouble with nci_test.o, so commented out from Makefile as a
quick hack
* Had trouble building dynclasses (flag/symbol problems)
Disabled for now
I've attached the result of a 'make test'. A number of tests fail
because I didn't compile the dynclasses or nci_test.o.
A large numer of failures are Aborts/Memory faults. Are these related to
the alignment problems raised by the compiler? Should I be overriding
something in the Configure script?
(Perhaps as a side effect of this?) I'm also seeing 'l != left'
assertions in mmd.c.
If there's any other information I can provide, feel free to ask!
Cheers,
Nick
Nick Glencross
Configure reported the following:
Determining your minimum pointer alignment......Use of uninitialized
value in concatenation (.) or string at config/auto/alignptrs.pl line 59.
Use of uninitialized value in numeric eq (==) atconfig/auto/alignptrs.pl
line 60.
.........for hpux: bytes.
Am going to investigate further...
Nick
Nick Glencross
> Actually, I'm working in a small window, and missed the fact that
> Configure reported the following:
>
> Determining your minimum pointer alignment......Use of uninitialized
> value in concatenation (.) or string at config/auto/alignptrs.pl line 59.
> Use of uninitialized value in numeric eq (==) atconfig/auto/alignptrs.pl
> line 60.
> ..........for hpux: bytes.
>
> Am going to investigate further...
It turns out that the warning is harmless, and doesn't affect
Configure's behaviour. There's a 'my $align = 4' which goes out of scope
before the message is printed.
Will submit a patch this evening, but it doesn't affect my 'make test' log.
Nick
Leopold Toetsch
> Here are some notes for those that are interested in parrot being built
> on other platforms.
>
> The system in question is a PA-RISC HP-UX 11.11 system
> (hppa2.0w-hp-hpux11.11). The system only has the bundled C compiler and
> linker, so I've compiled gcc 3.3.6 for it. gcc cannot create debug
> information without gas, which is unfortunately not supported on this
> platform.
>
> I also built Perl from source:
>
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
Strange - everything else looks like a 32-bit machine. Is it one?
> * *Lots* of this warning in the ops:
>
> ops/experimental.ops:285: warning: cast increases required
> alignment of target type
It would be helpful if you provided the core_ops*.c file that caused the
warning. Different run cores have different casts.
> * ld keeps being run with -g which is not a valid flag
What does "man ld" say about liking with debug info?
> * A warning is generated from cpp about the line in config.h as it
> contains a slash.
>
> #define PARROT_9000/800 1
Seems to be a platform/machine or such name. Again with a bit context it
could be easiliy deduced what variable got substiuted here - config.h is
generated - have a look at it's header.
> I've attached the result of a 'make test'.
This doesn't help yet. First the compiler has to get it right.
leo
Nick Glencross
> Here are some notes for those that are interested in parrot being built
> on other platforms.
>
> The system in question is a PA-RISC HP-UX 11.11 system
> (hppa2.0w-hp-hpux11.11). The system only has the bundled C compiler and
> linker, so I've compiled gcc 3.3.6 for it. gcc cannot create debug
> information without gas, which is unfortunately not supported on this
> platform.
> A large numer of failures are Aborts/Memory faults.
Although I can't compile with debugging, and hence find the exact line
where things die, I can of course trace to get an idea of where things
happen.
dumper_6.pir:
dumper_8.pir:
dumper_15.pir:
sort_*.pir:
69 cmp_str I30, P14, P13 - I30=3, P14=PerlString=PMC(0x4020c2d0
Str:"test2"), P13=PerlString=PMC(0x4020c330 Str:"array")
(PMCs are sometimes PerlInts, sometimes PerlStrings etc. Occasionally
cmp_strs succeed and don't always die first time)
getopt_long_1.pir:
858 i_concatenate P15, S15 - P15=String=PMC(0x4020a710 Str:""),
S15=".sub _pge_rule\n"
Assertion failed: l != left, file src/mmd.c, line 737
Abort(coredump)
jit_54.pasm:
9 i_divide P0, N0 - P0=Integer=PMC(0x4020cf90: 123),
N0=4000.000000
Assertion failed: l != left, file src/mmd.c, line 684
Abort(coredump)
lexicals_4.pasm:
33 eq P1, P2, 6 -
P1=Integer=PMC(0x4020ced0:1),P2=Integer=PMC(0x4006d5a8: 0),
Memory fault(coredump)
complex_16.pasm:
complex_24.pasm:
17 eq P0, P1, 6 - P0=Complex=PMC(0x4020cf90: 2+3i),
P1=Complex=PMC(0x4020cf78: 2+3i),
Memory fault(coredump)
coroutine_6.pir:
85 i_add P16, 1 - P16=Integer=PMC(0x4020cf30: 0),
Assertion failed: l != left, file src/mmd.c, line 631
Abort(coredump)
That's probably enough... It looks like all sorts of instructions and
PMC usages are causing deaths.... [On a positive note, the vast majority
of the tests pass]
Regards,
Nick
Leopold Toetsch
> #define PARROT_9000/800 1
^
Can you check in config/*/*.pl where that is coming from?
Thanks,
leo
Leopold Toetsch
> Doh! Copied the wrong 'perl -V' output!
>
> intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
> ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=4
> alignbytes=8, prototype=define
^^^^^^^^^^^^
What does this mean in perl?
leo
Nicholas Clark
It's the result from this C program run by Configure:
#include <stdio.h>
struct foobar {
char foo;
NV bar;
} try_algn;
int main()
{
printf("%d\n", (int)((char *)&try_algn.bar - (char *)&try_algn.foo));
return(0);
}
"alignbytes" isn't the most helpful name. NV is usually a double.
Nicholas Clark
Nick Glencross
That would be PARROT_${jitcpu}, where jitcpu is set by
config/auto/jit.pl. It looks like jitcpu is derived (through archname)
by splitting Perl's archname variable at the '-'.
I won't have access to the HP-UX system until Friday, but I recall that
doing a 'uname -a' showed that one of the fields was certainly 9000/800.
It sounds like a case of adding some special cases in jit.pl.
I guess that just doing a s|/|_|g would be a good start.
When I get access, I'll also see if the alignment test hangs as one of
the comments suggests, or whether I get a meaningful value returned.
Cheers,
Nick
Nick Glencross
>On Wed, 01 Jun 2005 12:45:12 +0100, Nick Glencross
><ni...@glencros.demon.co.uk> wrote:
>
>
>>Here are some notes for those that are interested in parrot being built
>>on other platforms.
>>
>>The system in question is a PA-RISC HP-UX 11.11 system
>>(hppa2.0w-hp-hpux11.11). The system only has the bundled C compiler and
>>linker, so I've compiled gcc 3.3.6 for it. gcc cannot create debug
>>information without gas, which is unfortunately not supported on this
>>platform.
>>
>>
>
>It is. Go fetch from my site!
>
>
Brilliant! When I first tried to compile binutils, configure said that
gas wasn't supported and it would skip the directory. Going into the gas
directory directly the configure script said something similar.
What was I doing wrong? Anyhow, I'll just use your build when I get back
onto the system.
Cheers,
Nick
H.Merijn Brand
<ni...@glencros.demon.co.uk> wrote:
> Here are some notes for those that are interested in parrot being built
> on other platforms.
>
> The system in question is a PA-RISC HP-UX 11.11 system
> (hppa2.0w-hp-hpux11.11). The system only has the bundled C compiler and
> linker, so I've compiled gcc 3.3.6 for it. gcc cannot create debug
> information without gas, which is unfortunately not supported on this
> platform.
It is. Go fetch from my site!
My HP ITRC site pages can be found at (please use LA as primary choice):
USA Los Angeles http://mirrors.develooper.com/hpux/
SGP Singapore https://www.beepz.com/personal/merijn/
USA Chicago http://ww.hpux.ws/merijn/
NL Hoofddorp http://www.cmve.net/~merijn/
gcc-3.4.4 + binutils-2.16 uploaded this morning, so it will be available
tomorrow after the sync.
gcc-4.0.0 proved to be unusable for perl-5.8.7 and blead in 64bit mode
if you restrict yourself to 32bit, it'll work fine
Enjoy, have FUN! H.Merijn
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11,
AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org, perl QA: http://qa.perl.org
reports to: smokers...@perl.org, per...@perl.org
Leopold Toetsch
This seems to indicate that double's have to be fetched from memory
locations % 8. Given all the warnings in core_ops*.c I've the gut
feeling that this platform has more such alignment constraints, which
are all not checked by the config system.
> Nicholas Clark
leo
Peter Sinnott
> Leopold Toetsch wrote:
>
> >Nick Glencross wrote:
> >
> >>#define PARROT_9000/800 1
> >
> > ^
> >
> >Can you check in config/*/*.pl where that is coming from?
>
> That would be PARROT_${jitcpu}, where jitcpu is set by
> config/auto/jit.pl. It looks like jitcpu is derived (through archname)
> by splitting Perl's archname variable at the '-'.
>
> I won't have access to the HP-UX system until Friday, but I recall that
> doing a 'uname -a' showed that one of the fields was certainly 9000/800.
> It sounds like a case of adding some special cases in jit.pl.
>
bash-2.05$ uname -a
HP-UX gnbil2dv B.11.00 A 9000/800 1657309373 two-user license
bash-2.05$ /cm/tools/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=hpux, osvers=11.00, archname=PA-RISC2.0
uname='hp-ux cmhp01 b.11.00 a 9000800 131901507 two-user license '
> I guess that just doing a s|/|_|g would be a good start.
>
> When I get access, I'll also see if the alignment test hangs as one of
> the comments suggests, or whether I get a meaningful value returned.
>
From cvs :
Determining your minimum pointer alignment..............for hpux: 4 bytes.
With hpux hard code commented out :
Determining your minimum pointer alignment........................ 4 bytes.
The comment in the hardcode says it is for HP-UX 10.20 so maybe 11 never
hung. Same answer anyway so no harm done(probably)
> Cheers,
>
> Nick
>
--
It's our responsibility to competently administrate emerging products while
continuing to assertively utilize multimedia based catalysts for change
to exceed customer expectations
Nick Glencross
>On Thu, Jun 02, 2005 at 11:22:45AM +0100, Nick Glencross wrote:
>
>
>>Peter Sinnott wrote:
>>
>>
>>
>>>bash-2.05$ uname -a
>>>
>>>HP-UX gnbil2dv B.11.00 A 9000/800 1657309373 two-user license
>>>bash-2.05$ /cm/tools/bin/perl -V
>>>Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
>>>Platform:
>>>osname=hpux, osvers=11.00, archname=PA-RISC2.0
>>>uname='hp-ux cmhp01 b.11.00 a 9000800 131901507 two-user license '
>>>
>>>
>>>
>>>
>>>
>>>>I guess that just doing a s|/|_|g would be a good start.
>>>>
>>>>When I get access, I'll also see if the alignment test hangs as one of
>>>>the comments suggests, or whether I get a meaningful value returned.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>From cvs :
>>>Determining your minimum pointer alignment..............for hpux: 4 bytes.
>>>
>>>
>>>With hpux hard code commented out :
>>>Determining your minimum pointer alignment........................ 4 bytes.
>>>
>>>
>>>The comment in the hardcode says it is for HP-UX 10.20 so maybe 11 never
>>>hung. Same answer anyway so no harm done(probably)
>>>
>>>
>>>
>>Great! That saves me doing tomorrow's experiment. Have you done a build
>>to see if you get similar behaviour to me?
>>
>>
>
>Alas my attempts to build fail at the link stage. gcc 2.95 fails
>as stuff isn't compiled correctly with position independent code and
>nothing I try with fpic/fPIC/shared will please it. gcc 3.3 fails
>saying there are references to variables that do not exist and the
>variable looks like some scary internal hp(not parrot) variable as it
>starts with a _. I may try building again tomorrow but probably will
>play about with the solaris failures today.
>
>
>
Is this in the dynclasses directory or the nci stuff?
If so, in the top-level makefile, find the 'all :' section and remove
the dependency on $(LIBNCI_TEST_SO) by just removing the line.
Then in dynclasses/Makefile, just replace the whole file with 'all:'.
That should allow the parrot binary to be built,
Nick
Peter Sinnott
> Peter Sinnott wrote:
>
> >
> >HP-UX gnbil2dv B.11.00 A 9000/800 1657309373 two-user license
> >bash-2.05$ /cm/tools/bin/perl -V
> >Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
> >Platform:
> >osname=hpux, osvers=11.00, archname=PA-RISC2.0
> >uname='hp-ux cmhp01 b.11.00 a 9000800 131901507 two-user license '
> >
> >
> >
> >>I guess that just doing a s|/|_|g would be a good start.
> >>
> >>When I get access, I'll also see if the alignment test hangs as one of
> >>the comments suggests, or whether I get a meaningful value returned.
> >>
> >>
> >>
> >
> >>From cvs :
> >Determining your minimum pointer alignment..............for hpux: 4 bytes.
> >
> >
> >With hpux hard code commented out :
> >Determining your minimum pointer alignment........................ 4 bytes.
> >
> >
> >The comment in the hardcode says it is for HP-UX 10.20 so maybe 11 never
> >hung. Same answer anyway so no harm done(probably)
> >
> to see if you get similar behaviour to me?
Alas my attempts to build fail at the link stage. gcc 2.95 fails
as stuff isn't compiled correctly with position independent code and
nothing I try with fpic/fPIC/shared will please it. gcc 3.3 fails
saying there are references to variables that do not exist and the
variable looks like some scary internal hp(not parrot) variable as it
starts with a _. I may try building again tomorrow but probably will
play about with the solaris failures today.
>
> Looks like this morning's HP-UX configure patch has worked, good. You're
> still using cvs I see...
>
Using cvs? I am using a snv snapshot from yesterday.
Nick Glencross
> On Wed, 01 Jun 2005 12:45:12 +0100, Nick Glencross
> <ni...@glencros.demon.co.uk> wrote:
>
>
>>Here are some notes for those that are interested in parrot being built
>>on other platforms.
>>
>>The system in question is a PA-RISC HP-UX 11.11 system
>>(hppa2.0w-hp-hpux11.11). The system only has the bundled C compiler and
>>linker, so I've compiled gcc 3.3.6 for it. gcc cannot create debug
>>information without gas, which is unfortunately not supported on this
>>platform.
>
>
> It is. Go fetch from my site!
Having downloaded the version of gas from H.Merijn's site, I've now
recompiled gcc against it and have debugging support on HP-UX (I'm
still using the system ld for the timebeing).
Strangely all the segfaults have now gone away (perhaps the assembler
aligns data differently?), although the 'l != left' assertions are still
there.
There are quite a lot, and some are listed here. This lists the failed
test, and the line number that the assertion occurs in mmd.c.
TEST: mmd assertion line number
getopt_long_1.pir: 727
jit_54.pasm: 676
coroutine_6.pir: 625
coroutine_12.pir: 625
float_[16,17,18,19,20,21,22,23].pasm: 625 and 676
integer_1.pir: 625
perlint_[12,15,16,17,18,19,20,21,23,35,36,37,38,39,40,41,42,35,36,37,...]:
625 & 676
...
I shall obviously be investigating these in more detail.
Briefly, getopt_long_1.pir seems to assert on the following instruction.
858 i_concatenate P15, S15 - P15=String=PMC(0x4020a740 Str:""),
S15=".sub _pge_rule\n"
and jit_54.pasm asserts on this instruction:
9 i_divide P0, N0 - P0=Integer=PMC(0x4020d3c8: 123),
N0=4000.000000
If someone can give me any insight into what this assertion is checking,
I'd be grateful. It seems to boil down to whether the left PMC is a
deleg pmc (else left is assigned to l, and the assertion fires).
I've also attached a patch to rename the CPU arch which causes warnings
from config.h. If someone can apply this (or a variant if you don't like
the '|'s) I'd be grateful. Failing that, I'll log a call this evening
when I have access to an SMTP server.
Cheers,
Nick
Leopold Toetsch
> Strangely all the segfaults have now gone away (perhaps the assembler
> aligns data differently?), although the 'l != left' assertions are still
> there.
Looking at the code this is very likely caused by unaligned function
pointers. To verify it please set:
#define PARROT_HASH_ALIGNED_FUNCPTR 0
in include/parrot/has_header.h
(after Configure.pl) - then "make".
Thanks,
leo
Leopold Toetsch
> + # This was added to convert 9000/800 to 9000_800 on HP-UX
> + $cpuarch =~ s|/|_|g;
Thanks, applied - r8264
leo
Nick Glencross
> Nick Glencross wrote:
>
>> Strangely all the segfaults have now gone away (perhaps the assembler
>> aligns data differently?), although the 'l != left' assertions are
>> still there.
>
>
> Looking at the code this is very likely caused by unaligned function
> pointers. To verify it please set:
>
> #define PARROT_HASH_ALIGNED_FUNCPTR 0
Shame, that doesn't seem to have made any difference, even though I had
my fingers crossed. :-(
I'll revisit this later this afternoon; just looking at dynclasses at
the moment.
Nick
Nick Glencross
> Leopold Toetsch wrote:
>
>> Nick Glencross wrote:
>>
>>> Strangely all the segfaults have now gone away (perhaps the assembler
>>> aligns data differently?), although the 'l != left' assertions are
>>> still there.
>>
>>
>>
>> Looking at the code this is very likely caused by unaligned function
>> pointers. To verify it please set:
>>
>> #define PARROT_HASH_ALIGNED_FUNCPTR 0
Actually, where it uses this in mmd.c is actually an #ifndef which means
that really the above line should be commented out.
Brilliant! That seems to have fixed it! (Thanks Leo!)
I've made some progress on the dynclasses too. Where the libraries are
copied into runtime/parrot/dynext they lose their execute flag, which is
really important to HP-UX. I'll provide a patch this evening which will
probably replace copy with syscopy in build_dynclasses.pl.
Still some hangs in dynamic loading, but real close now...
Regards,
Nick
Leopold Toetsch
>> Leopold Toetsch wrote:
>>> #define PARROT_HASH_ALIGNED_FUNCPTR 0
> Actually, where it uses this in mmd.c is actually an #ifndef which means
> that really the above line should be commented out.
The various HPUX-related changed didn't make it into the release, sorry.
Could you please provide a patch for all outstanding issued.
Thanks,
leo
Nick Glencross
> The various HPUX-related changed didn't make it into the release, sorry.
>
>Could you please provide a patch for all outstanding issued.
>
Leo,
Not a problem. I'm attaching a patch which I believe fixes all the build
issues on HP-UX, and shouldn't cause any breakage with any other platforms.
I've retested on Linux and cygwin (although cygwin has problems with
dynclasses), and all's well.
A summary of the changes:
* Two extra flags are made available (cc_shared, which was already
extracted from Perl but not used, and ccdlflags, which probably needs a
better name!), and added to the makefile etc.
* I've removed -g from ld_debug, hopefully not upsetting anyone.
Platforms that need it should probably add it as I would have thought
that they are in the minority; can a Solaris person confirm that it's ok
for them.
* Turn off aligned_funcptr for HP-UX; is that ok how I've done it?
With this patch HP-UX builds 'out of the box' for me (as hopefully will
other future platforms), but we still need a viable solution to get
execute permissions onto libraries in runtime/parrot/dynext/*.
The signal test fails due to the shell, and two of the nci tests hangs.
I've attached a separate patch (not for committing!) which makes these
two tests fail so that things run to completion. The manifest test which
I had failing in the past was purely because I didn't have svn installed
even though I had the .svn files.
The patch seems safe enough... Is it ok to apply straight away, or
should let a few people try it before applying?
Thanks in advance,
Nick
Leopold Toetsch
> Not a problem. I'm attaching a patch which I believe fixes all the build
> issues on HP-UX, and shouldn't cause any breakage with any other platforms.
Thanks, applied - r8280
leo
Andy Dougherty
> Not a problem. I'm attaching a patch which I believe fixes all the build
> issues on HP-UX, and shouldn't cause any breakage with any other platforms.
>
> I've retested on Linux and cygwin (although cygwin has problems with
> dynclasses), and all's well.
>
> A summary of the changes:
>
> * Two extra flags are made available (cc_shared, which was already extracted
> from Perl but not used, and ccdlflags, which probably needs a better name!),
> and added to the makefile etc.
Agreed -- ccdlflags indeed does need a better name. I'd suggest
link_dynamic, since it's really the flags to be supplied to the linker
that allow it to be used with shared and dynamically loaded libraries.
(Perl5's Configure confuses things by usually using $cc for linking as
well.)
(Or, perhaps, link_shared -- Darwin distinguishes between shared libraries
and dynamically loaded libraries. I'm not sure which is more relevant
here.)
The patch below goes on top of yours and renames it link_shared.
diff -r -u parrot-orig/config/gen/makefiles/root.in parrot-andy/config/gen/makefiles/root.in
--- parrot-orig/config/gen/makefiles/root.in Mon Jun 6 09:14:16 2005
+++ parrot-andy/config/gen/makefiles/root.in Mon Jun 6 13:29:04 2005
@@ -87,7 +87,7 @@
CFLAGS = ${ccflags} ${cc_debug} ${ccwarn} $(CC_INC) ${cc_hasjit} ${cg_flag} ${gc_flag}
C_LIBS = ${libs}
CC_SHARED = ${cc_shared}
-CCDLFLAGS = ${ccdlflags}
+LINK_DYNAMIC = ${link_dynamic}
LINK = ${link}
LINKFLAGS = ${linkflags} ${link_debug} ${ld_debug}
LD = ${ld}
@@ -651,7 +651,7 @@
$(PARROT) : $(IMCC_DIR)/main$(O) $(GEN_HEADERS) $(LIBPARROT) \
lib/Parrot/OpLib/core.pm $(SRC_DIR)/parrot_config$(O) \
$(MINIPARROT)
- $(LINK) ${ld_out}$(PARROT) $(LINKFLAGS) $(CCDLFLAGS) \
+ $(LINK) ${ld_out}$(PARROT) $(LINKFLAGS) $(LINK_DYNAMIC) \
$(IMCC_DIR)/main$(O) $(ALL_PARROT_LIBS) $(SRC_DIR)/parrot_config$(O)
#
# TODO build the real miniparrot
diff -r -u parrot-orig/config/init/data.pl parrot-andy/config/init/data.pl
--- parrot-orig/config/init/data.pl Mon Jun 6 09:12:51 2005
+++ parrot-andy/config/init/data.pl Mon Jun 6 11:18:14 2005
@@ -51,10 +51,6 @@
# with position-independent code suitable for dynamic loading.
cc_shared => $Config{cccdlflags}, # e.g. -fpic for GNU cc.
- # Compiler flags used to allow dynamic libraries to access the
- # binary's symbols
- ccdlflags => $Config{ccdlflags}, # e.g. -Wl,-E on HP-UX
-
# C++ compiler -- used to compile parts of ICU. ICU's configure
# will try to find a suitable compiler, but it prefers GNU c++ over
# a system c++, which might not be appropriate. This setting
@@ -71,6 +67,10 @@
# make a reasonable guess at defaults.
link => $Config{cc},
linkflags => $Config{ldflags},
+ # Linker Flags to have this binary work with the shared and dynamically
+ # loadable libraries we're building. On HP-UX, for example, we need to
+ # allow dynamic libraries to access the binary's symbols
+ link_dynamic => $Config{ccdlflags}, # e.g. -Wl,-E on HP-UX
# ld: Tool used to build shared libraries and dynamically loadable
# modules. Often $cc on Unix-ish systems, but apparently sometimes
--
Andy Dougherty doug...@lafayette.edu
Nick Glencross
>On Mon, 6 Jun 2005, Nick Glencross wrote:
>
>
>
>>Not a problem. I'm attaching a patch which I believe fixes all the build
>>issues on HP-UX, and shouldn't cause any breakage with any other platforms.
>>
>>I've retested on Linux and cygwin (although cygwin has problems with
>>dynclasses), and all's well.
>>
>>A summary of the changes:
>>
>> * Two extra flags are made available (cc_shared, which was already extracted
>>from Perl but not used, and ccdlflags, which probably needs a better name!),
>>and added to the makefile etc.
>>
>>
>
>Agreed -- ccdlflags indeed does need a better name. I'd suggest
>link_dynamic, since it's really the flags to be supplied to the linker
>that allow it to be used with shared and dynamically loaded libraries.
>(Perl5's Configure confuses things by usually using $cc for linking as
>well.)
>
>
Yea, this variable is clearly a C compiler-used-as-a-linker flag. How
about cc_link_dynamic?
Nick
Andy Dougherty
I see your point, but I think not. This flag is to be used by the
$Config{link} program, so it should be named link_something. It is true
that on most Unix-like systems, 'linking' is best done by the C-compiler
front end, but that's not generally true elsewhere.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> The patch below goes on top of yours and renames it link_shared.
Thanks, applied - r8284
leo