Re: [perl #37841] build faild in src/embed.c line 373 MAP_FAILED undeclared
this is an older slackware derivative with one of the last libc5 systems, May 13 1998 libc.so.5 -> libc.so.5.4.44* Feb 1 1998 libc.so.5.4.44* but it does use recent (2.4.32) kernel header files. On Mon, 5 Dec 2005 at 06:34 -0800, Leopold Toetsch via RT From: Leopold Toetsch via RT <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Mon, 5 Dec 2005 06:34:17 -0800 Subject: Re: [perl #37841] build faild in src/embed.c line 373 MAP_FAILED undeclared On Dec 5, 2005, at 8:03, David Dyck (via RT) wrote: checked out todays version and found the following build error: src/embed.c: In function `Parrot_readbc': src/embed.c:373: `MAP_FAILED' undeclared (first use in this function) Strange. Which linux and libc version is this? Anyway, I've checked in r10346, which defines it to -1, if it isn't yet. HTH, leo
Re: [perl #37906] socklen_t not defined
On Sun, 26 Feb 2006 at 07:31 -0800, Bernhard Schmalhofer via RT...:
From: Bernhard Schmalhofer via RT <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Sun, 26 Feb 2006 07:31:10 -0800
Subject: [perl #37906] socklen_t not defined
Hi David,
why does parrot expect socklen_t to be defined?
Since it isn't on my OLD libc5 system, parrot doesn't build
thanks for reporting this bug.
I have looked into it and added a config probe to Parrot,
asking Perl5's Config module, whether 'socklen_t' is there.
'int' is used by when there is no 'socklen_t'.
Could you upgrade to SVN revision 11750 or later, checking whether
Parrot now compiles with libc5?
I got a little further with a new error in the link phase, although these
errors in src/exec_save.c Parrot_exec_save()
c++ -o miniparrot -L/usr/local/lib -Wl,-E compilers/imcc/main.o \
-Wl,-rpath=/hdd1/jd/usr2/dcd/ftp2/ponie/ponie/parrot/blib/lib
-L/hdd1/jd/usr2/dcd/ftp2/ponie/ponie/parrot/blib/lib -lparrot -ldl -lm -
lpthread src/null_config.o
/hdd1/jd/usr2/dcd/ftp2/ponie/ponie/parrot/blib/lib/libparrot.so: undefined
reference to `ELF32_ST_INFO'
/hdd1/jd/usr2/dcd/ftp2/ponie/ponie/parrot/blib/lib/libparrot.so: undefined
reference to `inet_pton'
/hdd1/jd/usr2/dcd/ftp2/ponie/ponie/parrot/blib/lib/libparrot.so: undefined
reference to `ELF32_R_INFO'
collect2: ld returned 1 exit status
make: *** [miniparrot] Error 1
I did see in
http://www.busybox.net/lists/busybox-cvs/2003-July/004266.html
where busybox added lines like
#ifndef ELF32_ST_INFO
# define ELF32_ST_INFO(bind, type) (((bind) << 4) + ((type) & 0xf))
#endif
to support ancient c libraries (line mine :-)
and I can see
#define ELF32_R_INFO(s,t) (((s) << 8) + ((t) & 0xff))
in my binutils source file include/elf/common.h
but I'm not sure why I get the undefined reference to `inet_pton', as there
seems
to be conditional code that wraps it in src/io/io_unix.c
#ifdef PARROT_DEF_INET_ATON
if (inet_aton(s, &sa.sin_addr) != 0) {
#else
if (inet_pton(family, s, &sa.sin_addr) != 0) {
#endif
but there is no definition of PARROT_DEF_INET_ATON anywhere
but it looks like I should have added --define=inet_aton
perl Configure.pl --define=inet_aton
After adding code to provide definitions for ELF32_ST_INFO and ELF32_R_INFO, and
adding the --define=inet_aton, I was able to link a new miniparrot and parrot
and start the tests.
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/compilers/imcc/syn/file.t1 256121 8.33% 11
t/perl/Parrot_IO.t 255 6528055 77 140.00% 17-55
9 tests and 392 subtests skipped.
Failed 2/228 test scripts, 99.12% okay. 40/5635 subtests failed, 99.29% okay.
Re: [perl #37906] socklen_t not defined
On Sat, 4 Mar 2006 at 08:52 -0800, Bernhard Schmalhofer via RT...:
could you send your changes as a patch to me or to [EMAIL PROTECTED]
my hack was not how anyone should implement it.
(I was just trying to get it to compile)
Could you additionally add your test results to PLATFORMS?
I tried find a bit more documentation on the information needed
to add to PLATFORMS, but didn't find it yet in parrot - any advice?
I suppose there needs to be some kind of config check for older 'libc5'.
The hints you passed to Configure.pl could probably also be put into a
hints file.
See below
Index: parrot/src/exec_save.c
===
--- parrot/src/exec_save.c (revision 11768)
+++ parrot/src/exec_save.c (working copy)
@@ -300,6 +300,11 @@
save_struct(fp, obj->text.code, obj->text.size); /* Text */
save_struct(fp, obj->data.code, obj->data.size); /* Data */
/* Text rellocations */
+
+#ifndef ELF32_R_INFO
+# define ELF32_R_INFO(s,t) (((s) << 8) + ((t) & 0xff))
+#endif
+
for (i = 0; i < obj->text_rellocation_count; i++) {
# if PARROT_I386
bzero(&rellocation, sizeof(Elf32_Rel));
@@ -399,6 +404,11 @@
save_struct(fp, &symlst, sizeof(Elf32_Sym));
/* Text */
bzero(&symlst, sizeof(Elf32_Sym));
+
+#ifndef ELF32_ST_INFO
+# define ELF32_ST_INFO(bind, type) (((bind) << 4) + ((type) & 0xf))
+#endif
+
symlst.st_info = ELF32_ST_INFO(STB_LOCAL, STT_SECTION);
symlst.st_shndx = 2;
save_struct(fp, &symlst, sizeof(Elf32_Sym));
"average perl users"? was: labeled if blocks
On Mon, 28 Oct 2002 at 14:50 -0800, Larry Wall <[EMAIL PROTECTED]> wrote: > On Tue, 29 Oct 2002, Angel Faus wrote: > : Could we please, please, please have bitwise operators be out of the > : core. We expect that they are not going to be used by the average > : user, so it looks fair to apply the ultimate negative huffman > : enconding: they need to be specially required. > : > : A simple "use bitwise" would be ok. That would provide a proper > : manpage to explain the meta-operators thing, and would shorten the > : main list, which is something that we desperatelly need. > > Fine by me. Could force people to declare hyper and super, for all that... I admit that I use pack, bitwise operators, as well as 0x constants in many of my scripts. I'm not sure what Angel means by taking some of these things out of the core, but if my short perl5 scripts start to grow to python length I'll have less incentive to move in the perl6 direction. For now I'll just hope that most of the people driving perl6 know what the average users are going to do with perl6. Isn't the average perl user using perl5 now? David
email encoding of the french quote characters (ISO_8859_1 0xab and 0xbb)
On Wed, 30 Oct 2002 at 12:17 -0800, Michael Lazzaro <[EMAIL PROTECTED]: > On Wednesday, October 30, 2002, at 11:58 AM, Larry Wall wrote: > > I'd even be willing to give up ´foo bar bazª meaning qw(foo bar baz) > > for this. > > I can't see that right (MacOSX Jaguar) in the email; to me it looks > like a forwardtick and an, um, underlined 'a' -- but in spite of that, > I'm game. It's just so pretty (when it works!) > > On my Mac, it's spelled «op» -- can others see that correctly, or do we > have a sorry disconnect in the fonts, here, for us Mac folks? This concerns me, so forgive this partial digression. When I tried to read Larry's message there were no characters around the foo bar bas (which arrived as Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT) I just saw "I'd even be willing to give up foo bar baz meaning qw(foo bar baz) for this." in both pine and lookout, and my spool files. I was quite surprized when I saw Larry's message quoted with the characters in question in Austin's message (arrived as Content-Type: text/plain; charset=us-ascii) > I'd even be willing to give up «foo bar baz» meaning qw(foo bar baz) > for this. How did they get transformed to the funny 0xb4 and 0xaa characters in Micheal's quote. (arrived as Content-Transfer-Encoding: quoted-printable_ ISO_8859_1 253 171 AB « LEFT-POINTING DOUBLE ANGLE QUOTATION MARK 273 187 BB » RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
vote no - Re: Unicode operators [Was: Re: UTF-8 and Unicode FAQ, demos]
The first message had many of the following characters viewable in my telnet window, but the repost introduced a 0xC2 prefix to the 0xA7 character. I have this feeling that many people would vote against posting all these funny characters, as is does make reading the perl6 mailing lists difficult in some contexts. Ever since introducing these UTF-8 > 127 characters into this mailing list, I can never be sure of what the posting author intended to send. I'm all for supporting UTF-8 characters in strings, and perhaps even in variable names but to we really have to have perl6 programs with core operators in UTF-8. I'd like to see all the perl6 code that had UTF-8 operators start with use non_portable_utf8_operators. As it stands now, I'm going to have to find new tools for my linux platform that has been performing fine since 1995 (perl5.9 still supports libc5!), and I don't yet know how I am going to be able to telnet in from win98, and I'll bet that the dos kermit that I use when I dial up won't support UTF-8 characters either. David ps. I just read how many people will need to upgrade their operating systems if the want to upgrade to MS Word11. Do we want to require operating system and/or many support tools to be upgraded before we can share perl6 scripts via email? On Tue, 5 Nov 2002 at 09:56 -0800, Michael Lazzaro <[EMAIL PROTECTED]: > > CodeSymbol Comment > > 167 § Could be used > > 169 © Could be used > > 171 « May well be used > > 172 ¬ "Not"? > > 174 ® Could be used > > 176 ° Could be used > > 177 ± Introduces an interesting level of uncertainty? Useable > > 181 µ Could be used > > 182 ¶ Could be used > > 186 º Could be used (but I dislike it as it is alphabetic) > > 187 » May well be used > > 191 ¿ Could be used
Re: perl6-lang Project Management
On Thu, 7 Nov 2002 at 10:38 -0800, Michael Lazzaro <[EMAIL PROTECTED]: > I dunno anymore, maybe we need to rethink what place there is for > public domain docs at all. Perhaps we just have a man page that says > "buy the damn books, you cheapskate" and be done with it. I trust you were joking, right? I learned perl3 by reading the 62 pages of the manual. I learned perl4 by reading the 76 pages of the manual, and then bought the book. For perl5 I read much of the manual, and bought and read 4 books. (there are nearly 2000 pages of pod documentation for perl5.9, not counting the perldoc of the installed modules). I expect that perl6 will have more online documentation, and I'll probably learn from the new books I purchase. With out authoritive online documention I don't think that perl6 will go anywhere.
