Re: ponie-2 on x86 solaris 2.5.1
Nicholas Clark
from CPAN? If so, that's somewhat out of date, so this might be part of
the problems (but not all, I suspect).
All the errors you've reported so far appear to come from parrot, rather than
being ponie specific so it's probably better to shift this thread over to the
perl6-internals list, where the parrot folks live.
I'm not sure if anyone has ever tried to build parrot on Solaris 2.5, or on
Solaris x86. I've had some "fun" building it on prerelease Sparc Solaris 10,
but that was almost all down to ICU, and occurred much later in the build
than the problems you seem to be seeing.
On Tue, Dec 28, 2004 at 10:56:23PM -0600, Andy...@wiwb.uscourts.gov wrote:
For all on perl6-internals, the first message of this thread is
http://www.nntp.perl.org/group/perl.ponie.dev/359
and refers to the asctime_r errors.
> Now I see:
> ops/core_ops.c
> ops/io.ops: In function `Parrot_tell_i_i_p':
> ops/io.ops:507: warning: right shift count >= width of type
> ops/core_ops_prederef.c
> ops/io.ops: In function `Parrot_pred_tell_i_i_p':
> ops/io.ops:507: warning: right shift count >= width of type
> ops/core_ops_switch.c
> ops/io.ops: In function `switch_core':
> ops/io.ops:507: warning: right shift count >= width of type
> ops/core_ops_cg.c
> ops/io.ops: In function `cg_core':
> ops/io.ops:507: warning: right shift count >= width of type
>
> which points to:
> op tell(out INT, out INT, in PMC) {
> if ($3) {
> PIOOFF_T pos;
> pos = PIO_tell(interpreter, $3);
> $1 = (INTVAL)(pos >> 32);
> $2 = (INTVAL)(pos & 0xffffffff);
> }
> goto NEXT();
> }
>
>
> which means my PIOOFF_T is less than 32 bits? Hmm ...
I suspect that it means that your PIOOFF_T is exactly 32 bits, as the error
is ">=", not ">", and a shift of the width of the type is undefined behaviour
in C. Which would mean that the parrot code is buggy for the case of non-
large-files systems.
Are you using the Sun compiler, or gcc? I'm not sure which would produce
that warning, but my hunch would be the Sun compiler as shifts happen to be
modulo 32 on x86, but IIRC are modulo 256 on Sparc, hence it would be
something I'd expect a Sun compiler to spot, as it would be an easy
portability gotcha to fall into on Solaris.
Nicholas Clark
Leopold Toetsch
> Hi.
> I managed to finagle past the asctime_r errors by sticking:
> print OUT <<'END';
> #define _POSIX_PTHREAD_SEMANTICS
> END
> in:
> parrot/config/gen/config_h/feature_h.in
Does it harm, if we unconditionally include this define or should it be
defined just for this solaris version?
leo
Leopold Toetsch
>> ops/io.ops: In function `Parrot_tell_i_i_p':
>> ops/io.ops:507: warning: right shift count >= width of type
> I suspect that it means that your PIOOFF_T is exactly 32 bits
$ find include -name '*.h' | xargs grep PIOOFF_T
include/parrot/io.h:typedef Parrot_OFF_T PIOOFF_T;
include/parrot/io.h:typedef off_t PIOOFF_T;
include/parrot/io.h:typedef long PIOOFF_T;
...
The different typedefs are used depending on some OS defines, which
obviously isn't enough.
We need a test that checks the sizeof(off_t) and if the size is 32 bits,
we shouldn't do the shift by 32, but set the high word to 0.
> Nicholas Clark
Patches welcome,
leo
Leopold Toetsch
> I know its a sort of dead end OS but ...
> ld: fatal: library -lrt: not found
> parrot/config/init/hints/solaris.pl
The following 3 lines ...
> if ( $libs !~ /-lrt\b/ ) {
> $libs .= ' -lrt';
>}
... obviously have to follow the scheme used in perl/hints/solaris_2.sh,
i.e.:
add -lrt for solaris >= 2.7 and remove it for lower versions.
Patches welcome,
leo
Andy Bach
just gotten sucked, er, just joined the parrot world (dang O'Reilly books
;-) and I'm not sure how formal this list is or how much detail you'll
want off the bat. If these issues are too picayune at this point, I'll
desist. I can give the full perl/OS details too but don't know if that's
(pthreads oops aside) necessary yet. Most of the msgs I've seen so far
are a little higher level than this, though the archives do have some
similar sort of nigglings so ... I can help w/ the Sol x86 test beds, as
I've got 2.5.1 2.7 and 2.8 available. Too much junk below but I've got
the msg written. Sorry.
>> I managed to finagle past the asctime_r errors by sticking:
>> print OUT <<'END';
>> #define _POSIX_PTHREAD_SEMANTICS
>> END
>> in:
>> parrot/config/gen/config_h/feature_h.in
> Does it harm, if we unconditionally include this define or should it be
> defined just for this solaris version?
I've since tried the compile on Sol x86 2.7 and that ifdef was unneeded -
thinking harder, the 2.5.1 box in question has pthreads installed (PTHREAD
- D'oh!) which seems to say Configure is recognizing that but not setting
this obscure ifdef?
>> if ( $libs !~ /-lrt\b/ ) {
>> $libs .= ' -lrt';
>>}
> ... obviously have to follow the scheme used in perl/hints/solaris_2.sh,
> i.e.:
> add -lrt for solaris >= 2.7 and remove it for lower versions.
I did have to comment that out for 2.7 also.
My understanding is that < Sol 2.7 you don't get a snprintf. That's where
the next attempt failed on the 2.5.1 box along w/:
: blib/lib/libparrot.a
gcc -o parrot -L/usr/local/lib -L/usr2/local/lib -g imcc/main.o
blib/lib/libparrot.a -lsocket -lnsl -ldl -lm -lposix4 -lpthread -lcrypt
-lsec
Undefined first referenced
symbol in file
inet_pton blib/lib/libparrot.a(io_unix.o)
ld: fatal: Symbol referencing errors. No output written to parrot
io_unix.c has:
STRING *
PIO_sockaddr_in(theINTERP, unsigned short port, STRING * addr)
{
struct sockaddr_in sa;
/* Hard coded to IPv4 for now */
int family = AF_INET;
char * s = string_to_cstring(interpreter, addr);
#ifdef PARROT_DEF_INET_ATON
if(inet_aton(s, &sa.sin_addr) != 0) {
#else
if(inet_pton(family, s, &sa.sin_addr) != 0) {
#endif
As it happens, 2.5.1 has neither inet_aton or inet_pton
comment in the above:
XXX: We can probably just write our own routines (C<htons()>,
C<inet_aton()>, etc.) and take this out of platform specific compilation
parrot/config/auto/snprintf/test.in
The 2.7 doesn't have Sun's cc/CC (too expensive) and so
(config/init/hints/solaris.pl):
my $link = Configure::Data->get('link');
# Going to assume Sun's compiler
# In which case we need to link with the C++ compiler (CC) rather than the
# C compiler (cc)
$link =~ s/\bcc\b/CC/;
Configure::Data->set('link', $link);
...
choked early on:
Determining what C compiler and linker to
use.........................done.
Determining if your C compiler is actually gcc......Linker failed (see
test.ldo)
test.ldo
Can't exec "CC": No such file or directory at lib/Parrot/Configure/Step.pm
line 279.
which seems to say its not doing whatever that link stuff is doing, its
not working for the CC/g++ switch. Changing that subst:
# C compiler (cc)
#$link =~ s/\bcc\b/CC/;
# YAassumption - g++
$link =~ s/\bcc\b/g++/;
Configure::Data->set('link', $link);
whch gets us as far as:
: blib/lib/libparrot.a
g++ -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a
blib/lib/libicuuc.a blib/lib/libicudata.a -lsocket -lnsl -ldl -lm
-lpthread -lsched
Undefined first referenced
symbol in file
sched_yield blib/lib/libparrot.a(thread.o)
ld: fatal: Symbol referencing errors. No output written to parrot
2.7 (Sol. native threads?) does have sched_yield (in sched.h) but I dunno
how to best tell it which to use (posix or sun) or which is better.
a
Andy Bach, Sys. Mangler
Internet: andy...@wiwb.uscourts.gov
VOICE: (608) 261-5738 FAX 264-5932
Call out Gouranga be happy!!!
Gouranga Gouranga Gouranga ....
That which brings the highest happiness!!
Nicholas Clark
> Please let me know if I'm being too dense or too, er, flippant here, I've
No, you seem to be spot on.
> The 2.7 doesn't have Sun's cc/CC (too expensive) and so
> (config/init/hints/solaris.pl):
> my $link = Configure::Data->get('link');
> # Going to assume Sun's compiler
> # In which case we need to link with the C++ compiler (CC) rather than the
> # C compiler (cc)
> $link =~ s/\bcc\b/CC/;
> Configure::Data->set('link', $link);
> ...
> choked early on:
> Determining what C compiler and linker to
> use.........................done.
> Determining if your C compiler is actually gcc......Linker failed (see
> test.ldo)
>
> test.ldo
> Can't exec "CC": No such file or directory at lib/Parrot/Configure/Step.pm
> line 279.
>
> which seems to say its not doing whatever that link stuff is doing, its
> not working for the CC/g++ switch. Changing that subst:
> # C compiler (cc)
> #$link =~ s/\bcc\b/CC/;
> # YAassumption - g++
> $link =~ s/\bcc\b/g++/;
> Configure::Data->set('link', $link);
I think I might have been at least part responsible for that code to use
CC for linking. The problem is that the linker really needs to be set
correctly (either way) later on. I tried this (the machine I have only
has the Sun compiler):
# If we're using Sun's compiler then we need to link with the C++ compiler (CC)
# rather than the C compiler (cc)
# If it turns out we're using gcc, then we need to make sure we're linking
# with g++, not gcc. We can't make this decision until later, because the
# gcc test hasn't been run yet.
my $solaris_cb = sub {
my ($key, $gccversion) = @_;
my $link = Configure::Data->get('link');
if ($gccversion) {
$link =~ s/g?cc/g\+\+/;
} else {
$link =~ s/\bcc\b/CC/;
}
Configure::Data->set('link', $link);
Configure::Data->deltrigger("gccversion", "solaris_hints");
};
Configure::Data->settrigger("gccversion", "solaris_hints", $solaris_cb);
but it seems that that doesn't change 'link':
$ grep ^LINK Makefile LINK = ccache cc -D_XPG6
LINKFLAGS = -xarch=v9 -L/usr/lib/sparcv9 -L/usr/ccs/lib/sparcv9 -L/opt/SUNWspro/prod/lib/v9 -L/usr/local/lib -g
(should be CC)
so I'm inferring that that callback didn't get called when gccversion is
false. So this gets me to limit of my Parrot Configure knowledge - how do
we run a callback unconditionally after gccversion is known, independent
of its value?
Nicholas Clark