Re: Compiling Perl under b20.1

Re: Compiling Perl under b20.1

[Earnie Boyd]

---Sebastien Barre <Sebastien.Barre@utc.fr> wrote:
8<
> Any help ?
8<

I'm not familiar enough with perl or perl internals to comment on the
workings of perl; however, the default mode for CYGWIN is binmode. 
The only thing that [no]binmode changes is the processing mode of
pipes and redirection.  So adding and removing binmode from the CYGWIN
variable should not make any difference in the testing as both mean
the same.
==
-                        \\||//
-------------------o0O0--Earnie--0O0o-------------------
--                earnie_boyd@yahoo.com               --
-- http://www.freeyellow.com/members5/gw32/index.html --
----------------------ooo0O--O0ooo----------------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Earnie Boyd]

---Sebastien Barre <Sebastien.Barre@utc.fr> wrote:
8<
> Any help ?
8<

I'm not familiar enough with perl or perl internals to comment on the
workings of perl; however, the default mode for CYGWIN is binmode. 
The only thing that [no]binmode changes is the processing mode of
pipes and redirection.  So adding and removing binmode from the CYGWIN
variable should not make any difference in the testing as both mean
the same.
==
-                        \\||//
-------------------o0O0--Earnie--0O0o-------------------
--                earnie_boyd@yahoo.com               --
-- http://www.freeyellow.com/members5/gw32/index.html --
----------------------ooo0O--O0ooo----------------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Earnie Boyd]

---Charles Wilson <cwilson@ee.gatech.edu> wrote:
8<
> Now, all three of your patches address problems I didn't see; the
main difference
> between us being binary vs. text mounts. If that is the case, should
these tests
> be skipped for all cygwin (binary and text mount) or should the
tests be fixed so
> that they work for both binary and text mounts? I'm not sure if the
second option
> means hacking the test scripts, or hacking perl itself.
> 
8<

IMHO, it seems that the easiest fix for this would be for perl to
always open a script file in text mode processing.  Any file that can
be potentially created by a human with an editor should be opened for
text mode processing.
==
-                        \\||//
-------------------o0O0--Earnie--0O0o-------------------
--                earnie_boyd@yahoo.com               --
-- http://www.freeyellow.com/members5/gw32/index.html --
----------------------ooo0O--O0ooo----------------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Earnie Boyd wrote:

> ---Charles Wilson <cwilson@ee.gatech.edu> wrote:
> 8<
> > Now, all three of your patches address problems I didn't see; the
> main difference
> > between us being binary vs. text mounts. If that is the case, should
> these tests
> > be skipped for all cygwin (binary and text mount) or should the
> tests be fixed so
> > that they work for both binary and text mounts? I'm not sure if the
> second option
> > means hacking the test scripts, or hacking perl itself.
> >
> 8<
>
> IMHO, it seems that the easiest fix for this would be for perl to
> always open a script file in text mode processing.  Any file that can
> be potentially created by a human with an editor should be opened for
> text mode processing.

The issue is that the scripts in question directly open files themselves,
specifying O_RDWR | O_CREAT, etc. and test access to those files using
stat(). Thus the problem in these cases seem to be the scripts (and the
CYGWIN=ntea variable), not the perl exec itself.

Here's the three tests that failed for Sebastien but worked for me:

fs.t  FAILED tests 5,7,9,10
    each of these are testing access using stat(). I've got CYGWIN=ntea,
I'm guessing that Sebastien doesn't. Here is a representative part of
fs.t:

($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime,
    $blksize,$blocks) = stat('c');
if ($Is_Dosish) {print "ok 7 # skipped: no link\n";}
elsif (($mode & 0777) == 0777) {print "ok 7\n";}
else {print "not ok 7\n";}

sdbm.t  FAILED test 2, 5-18
    test 2 seems similar to the stat() problems above.
    tests 5-18 seem to involve a hashtable written to a file (I think),
and the behavior of that hashtable is then tested. If the file is on a
text mount, and but is opened in O_BINARY mode (ie. due to the
USEMYBINMODE  patch) then you get problems?

anydbm.t FAILED test 2, 5-12
    test 2 is another stat() problem
    tests 5-12 are similar to the the failed tests in sdbm.t.

Sebastien - try setting ntea and building perl again - but watch out for
those eadata files. Setting ntea, and using only my patch (not your
changes) should get rid of the failures in fs.t, and the failures of
test2 in sdbm and anydbm. At least, that's my guess.


--Chuck





--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 15:07 06/03/99 -0500, Charles Wilson wrote:

(some solutions, and some new problems regarding installation (new patch ?)
and Modules)


>Here's the three tests that failed for Sebastien but worked for me:
>
>fs.t  FAILED tests 5,7,9,10
>    each of these are testing access using stat(). I've got CYGWIN=ntea,
>I'm guessing that Sebastien doesn't. Here is a representative part of
>fs.t:

That's perfectly right, I was not using 'ntea' ! thanks to all of you for
this fix.
=> another information that might be worth adding to your build instructions :)

Here is the new result, *without* rebuilding perl :

Failed 6 test scripts out of 186, 91.40% okay.

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/anydbm.t      2   512    12    8  66.67%  5-12
lib/findbin.t                 1    1 100.00%  1
lib/sdbm.t        2   512    18   14  77.78%  5-18
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  2, 18-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 20 subtests skipped.
Failed 6/186 test scripts, 96.77% okay. 33/6191 subtests failed, 99.47% okay.

>sdbm.t  FAILED test 2, 5-18
>    test 2 seems similar to the stat() problems above.
>    tests 5-18 seem to involve a hashtable written to a file (I think),
>and the behavior of that hashtable is then tested. If the file is on a
>text mount, and but is opened in O_BINARY mode (ie. due to the
>USEMYBINMODE  patch) then you get problems?

>anydbm.t FAILED test 2, 5-12
>    test 2 is another stat() problem
>    tests 5-12 are similar to the the failed tests in sdbm.t.

All right, let's have a look at this binary problem. My files are on a text
mount, let's put all my partitions in binary mode, add 'binmode' to CYGWIN,
and launch the test (without rebuilding perl) :

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/findbin.t                 1    1 100.00%  1
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  4, 18-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 20 subtests skipped.
Failed 4/186 test scripts, 97.85% okay. 11/6191 subtests failed, 99.82% okay.

Bingo ! This is similar to you, except for this test (yours) :

op/stat.t                    58    2   3.45%  4, 35

I said that I did not use binary partitions because I had problem while
building Perl. Let's try again with this 'ntea' stuff set, and all your
patches : Perl build successfully this time (binary mount, 'binmode' in
CYGWIN).

Failed 4 test scripts out of 186, 92.47% okay.

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/findbin.t                 1    1 100.00%  1
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  2, 18-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 20 subtests skipped.
Failed 4/186 test scripts, 97.85% okay. 11/6191 subtests failed, 99.82% okay.

=> which is exactly the same as previously. This means that binary and/or
text mode *might not* (I'm still wondering)  influence the perl build, only
it's runtime behaviour, like tests.

Let's play :

no 'binmode' in CYGWIN + binary mount : same results, 4 tests failed !
no 'binmode' in CYGWIN + text mount : 6 tests failed (logical as it matchs
the beginning of this mail)
'binmode'  in CYGWIN + text mount : 4 tests failed (see above).

=> this seems to highlight your explanation. The sdbm and anydbm script
open files, and they will fail if these file are opened in text mode ? This
might be logical if these scripts try to read Unix-text files included in
the distribution, but is strange if they *create* these files, because
whatever the mode the translation should work (pb will raise only if
different text mode collide).

=> I do NOT know what to choose : binary mount and 'nobinmode' in CYGWIN,
or 'text mount' and 'binmode' in CYGWIN ? For now on, I guess I might
better mount my cygwin partitions as binary, so that build and tests of
classical Unix tools might have a better chance to succeed. But I choose
cygwin32 so that I might use Unix tools on (text) files created with
Windows software : what shall I do ? For sure, I will have to experiment :
leaving CYGWIN *without* 'binmode' for the moment, and if it fails, put
'binmode' back to CYGWIN... Any advice based on real-life experience ?

New interesting problems : 

-------------------------------
1) I was unable to install !! (what about you ?)

> make install
[...]
./perl installperl
/usr/local/bin is not writable by you
make: *** [install.perl] Error 2

The error message is located at this line in installperl :
-w $installbin		|| $nonono || die "$installbin is not writable by you\n"

But I'm using 'ntea' and made some unsuccessful 'chmod a+w /usr/local/bin'
!! This is driving me crazy !! 

I removed the line, and was able to install the perl binaries, libs and
headers (that also what I did before starting this whole discussion with you).

administrateur [545] /usr/local/src/perl5.005_02$ cd /usr/local/
administrateur [546] /usr/local$ ll
total 0
drwxr-xr-x   2 administ Aucun           0 Mar  7 22:54 bin/
[...]

My perl.exe is 966464 bytes long.

-------------------------------
2) Perl Modules 

Still using binary mount but no 'binmode' in CYGWIN, I tried to build (did
you too ?) some Perl modules (like DB_File, String-CRC) in /usr/local/src
(which is binary mounted). These modules produce libraries (CRC.a from
CRC.xs -> CRC.c for example) and have to be statically linked to perl.exe,
thus producing a new perl.exe (this is handled automatically by issuing :
make -f Makefile.aperl inst_perl MAP_TARGET=perl.exe).

  - build fails, with that kind of messages :
/usr/local/lib/perl5/5.00502/cygwin32/CORE/cw32imp.h:343: warning: this is
the location of the previous definition

meaning that cw32imp.h is included twice or more. Therefore, I disabled the
cw32imp.h inclusion from /usr/local/lib/perl5/00502/cygwin32/CORE/perl.h,
line 1242, and that fixed the problem. 

/* Work around some cygwin32 problems with importing global symbols */
#if defined(CYGWIN32) && defined(DLLIMPORT) 
/*
#   include "cw32imp.h"
*/
#endif

I know, this is really a dirty hack, did you notice the same problem, do
you think that it's worth a patch ? Let's investigate that problem.

 - test fails :
administrateur [600] /usr/local/src/String-CRC-1.0$ make test
[...]
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/B/extralibs
.ld >> blib/arch/auto/String/CRC/extralibs.all
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/DB_File/ext
ralibs.ld >> blib/arch/auto/String/CRC/extralibs.all
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Data/Dumper
/extralibs.ld >> blib/arch/auto/String/CRC/extralibs.all
[...]
gcc2 -L/usr/local/lib -o perl -O ./perlmain.o
blib/arch/auto/String/CRC/CRC.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/re/re.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/attrs/attrs
.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Socket/Sock
et.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/SDBM_File/S
DBM_File.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Opcode/Opco
de.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/IO/IO.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Fcntl/Fcntl
.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/DynaLoader/
DynaLoader.a

/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Data/Dumper
/Dumper.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/DB_File/DB_
File.a /d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/B/B.a
 /usr/local/lib/perl5/5.00502/cygwin32/CORE/libperl.a `cat
blib/arch/auto/String/CRC/extralibs.all` -lcygwin -lm -lc -lkernel32
/d/devel/gnuwin32/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld: cannot
open -
: No such file or directory
collect2: ld returned 1 exit status
make[1]: *** [perl] Error 1
make: *** [perl] Error 2


Playing with text mount, or 'binmode' in CYGWIN did not help. This error
was also reproducible with other modules... Package were extracted with tar
and gzip.

There is a suspicious 'cat' at the end of the gcc2 command. Seems to me
that there is an empty thing (or carriage return) in the extralibs.all that
produce the 'cannot open - <CR/LF> : No such file or directory'. Let's have
a look at it :

administrateur [527] /usr/local/src/String-CRC-1.0$ cat
blib/arch/auto/String/CRC/extralibs.all
=> it contains (34 bytes) the text '-L/usr/local/lib -ldb' surrounded by a
blank line and followed by many others.

administrateur [526] /usr/local/src/String-CRC-1.0$ od -x
blib/arch/auto/String/CRC/extralibs.all
0000000 2d0a 2f4c 7375 2f72 6f6c 6163 2f6c 696c
0000020 2062 6c2d 6264 0a0d 0a0a 0a0a 0a0a 0a0a
0000040 0a0a
0000042

Notice the '0a0d' !! But I was using both 'binmode' AND binary mount that
time, where the hell is this '0a0d' coming from ? (( 

That's *so* weird, I had NO problem to get rid of this module with my
previous Perl build and partitions mounted as text. Let's try again by
removing 'binmode' from my CYGWIN, and putting my partitions back to text
mode ! 

=> IT WORKS (noooooooo way). All tests successfull. What about
extralibs.all this time :

administrateur [527] /usr/local/src/String-CRC-1.0$ cat
blib/arch/auto/String/CRC/extralibs.all
=> it contains (*45* bytes) the text '-L/usr/local/lib -ldb' surrounded by
a blank line and followed by many others.

administrateur [526] /usr/local/src/String-CRC-1.0$ od -x
blib/arch/auto/String/CRC/extralibs.all
0000000 0a0d 4c2d 752f 7273 6c2f 636f 6c61 6c2f
0000020 6269 2d20 646c 0d62 0d0a 0d0a 0d0a 0d0a
0000040 0d0a 0d0a 0d0a 0d0a 0d0a 0d0a 000a
0000055

Notice this time that every '0a0d' works in 'pair' (they will be
'swallowed' as empty lines).

=> that explain the previous error message in binary mode : the linker
bumped on the 'Od', which was surrounded by 'Oa'
/d/devel/gnuwin32/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld: cannot
open -
: No such file or directory

Let's examine blib/arch/auto/String/CRC/extralibs.all more carefully (I'm
not a perl guru). It's build during 'make test' :

administrateur [600] /usr/local/src/String-CRC-1.0$ make test
[...]
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/B/extralibs
.ld >> blib/arch/auto/String/CRC/extralibs.all
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/DB_File/ext
ralibs.ld >> blib/arch/auto/String/CRC/extralibs.all

It seems to be the concatenation of information regarding previously
installed modules.  I looked at
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/*/extralibs
.ld, and ALL files are 1 bytes long, and this byte is... '0a", which
explains this row of 'Oa' at the end of extralibs.all.

I still do not know where this 'Od' comes from... 

Any help ?

______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Sebastien Barre wrote:

> At 15:07 06/03/99 -0500, Charles Wilson wrote:
>
> (some solutions, and some new problems regarding installation (new patch ?)
> and Modules)
>

WOW! You haven't been working on this all day, have you?

Let me summarize, and see if I've got this straight:
(1) according to Earnie Boyd (but contradicted by Pierre Humblet) CYGWIN=binmode
should have no effect. Two contradictory authorities, hmmm...we'll call this one an
open question. However, since CYGWIN=binmode is the default (?? - geez, I'm not
sure of *anything* anymore) and all of your tests were either CYGWIN=binmode or
CYGWIN=________, not CYGWIN=nobinmode, you really weren't changing anything here.
So, we'll throw that variable out.

(2) Text-mounted build, text-mounted tests, CYGWIN=__________. test results
(abbreviated version)

9 tests skipped, plus 20 subtests skipped.
Failed 7/186 test scripts, 96.24% okay. 39/6193 subtests failed, 99.37% okay.

(3) Text-mounted build, text-mounted tests, CYGWIN=ntea. test results

> 10 tests skipped, plus 20 subtests skipped.
> Failed 6/186 test scripts, 96.77% okay. 33/6191 subtests failed, 99.47% okay.

(4) Text-mounted build, binary-mounted test, CYGWIN=ntea binmode. test results

> 10 tests skipped, plus 20 subtests skipped.
> Failed 4/186 test scripts, 97.85% okay. 11/6191 subtests failed, 99.82% okay.
>
> Bingo ! This is similar to you, except for this test (yours) :
>
> op/stat.t                    58    2   3.45%  4, 35
>

Okay, digging into the stat.t code: You failed tests 18-20 and 26 in stat.t.  Tests
18-20 are testing (readable by owner?) (writeable by owner?) and (executable by
owner) after doing a chmod 0700. I can't remember if I was building perl under the
Administrator account or under my normal NT user account. But, the "everything
created by a member of the Administrators group belongs to the group, not the user"
NTism may be the culprit here.

Test 26 is testing (I just wrote this file. Do I own it?). Again, probably that
ugly NTism.

So, here's another item for the build-kit: {Do / Don't} build as an member of
Administrators group.

(5) Binary-mounted build, binary-mounted test, CYGWIN=ntea binmode.

So, you set ntea, (and binmode....), mounted everything binary, applied the
patches, and *rebuilt.* Rebuild was successful, and the test had similar (NOT
identical) results to (4) above. stat.t failed on tests "*2*, 18-20, 26, 35", not
"*4*, 18-20, 26, 35". Okay, what's the difference between tests 2 and 4? Well, I
don't completely understand them, but they seem to be comparing file-creation times
and file-modified times. I don't really get it. ????

> 10 tests skipped, plus 20 subtests skipped.
> Failed 4/186 test scripts, 97.85% okay. 11/6191 subtests failed, 99.82% okay.
>
> => which is exactly the same as previously. This means that binary and/or
> text mode *might not* (I'm still wondering)  influence the perl build, only
> it's runtime behaviour, like tests.

I believe you are correct. The only real difference between your original
text-mounted build / binary-mounted tests (with appropriate CYGWIN settings) -- ie.
number (4) -- and mine was the extra failures you got on op/stat.t, which I believe
are due to Administrators group problems.

(6) binary-mounted build, binary mounted test, CYGWIN=ntea
> same results (as (4) and (5)), 4 tests failed !

(7) binary-mounted build, text mounted test, CYGWIN=ntea
>  6 tests failed (same as (3))

(8) binary-mounted build, text mounted test, CYGWIN=ntea binmode
> same as (4) and (5)

My conclusions are the same as yours:
    (1) Earnie is right ==> binmode has no effect
    (2) binary mounted / text mounted don't affect the build, only the runtime
behavior and tests. Why is another question.

=> this seems to highlight your explanation. The sdbm and anydbm script

> open files, and they will fail if these file are opened in text mode ? This
> might be logical if these scripts try to read Unix-text files included in
> the distribution, but is strange if they *create* these files, because
> whatever the mode the translation should work (pb will raise only if
> different text mode collide).

Yup. Very strange. I don't really understand Perl all that well (I built the thing
so I could play with it...) I notice that the "problem" tests, anydbm and sdbm,
"open" the files using a construct like:

print (tie(%h,AnyDBM_File,'Op_dbmx', O_RDWR|O_CREAT, 0640)
    ? "ok 1\n" : "not ok 1\n");

I just assumed that the file-open flags would be passed to an fopen()-like function
directly, but maybe I was wrong...I dunno.

> => I do NOT know what to choose : binary mount and 'nobinmode' in CYGWIN,
> or 'text mount' and 'binmode' in CYGWIN ? For now on, I guess I might
> better mount my cygwin partitions as binary, so that build and tests of
> classical Unix tools might have a better chance to succeed. But I choose
> cygwin32 so that I might use Unix tools on (text) files created with
> Windows software : what shall I do ? For sure, I will have to experiment :
> leaving CYGWIN *without* 'binmode' for the moment, and if it fails, put
> 'binmode' back to CYGWIN... Any advice based on real-life experience ?
>

Well, your experiments show that binmode doesn't matter - besides, it's the
default. The only real issue here is that the CR/LF translation (which should be
invisible to the application ?) doesn't seem to be working properly when you've got
the partition mounted text.

Reply to the rest of your message in a followup (this one's getting way too long.)

--Chuck



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 02:19 08/03/99 -0500, Charles Wilson wrote:

>WOW! You haven't been working on this all day, have you?

Both of us :)

>Let me summarize, and see if I've got this straight:
>(1) according to Earnie Boyd (but contradicted by Pierre Humblet) 
[...]
>all of your tests were either CYGWIN=binmode or
>CYGWIN=________, not CYGWIN=nobinmode, you really weren't changing anything 
>here.

Sadly. I should have used nobinmode. I'll try.

>Okay, digging into the stat.t code: You failed tests 18-20 and 26 in stat.t. 
>Tests 18-20 are testing (readable by owner?) (writeable by owner?) and
(executable by
>owner) after doing a chmod 0700. I can't remember if I was building perl 
>under the Administrator account or under my normal NT user account. But,
the "everything
>created by a member of the Administrators group belongs to the group, not 
>the user" NTism may be the culprit here.

Yes, seems to me too, but I thought 'ntea' could solve this (see other
email "'ntea' CHECK please).

>My conclusions are the same as yours:
>    (1) Earnie is right ==> binmode has no effect
>    (2) binary mounted / text mounted don't affect the build, only the runtime
>behavior and tests. Why is another question.

OK for me at this time (+ a free headache).


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 02:19 08/03/99 -0500, Charles Wilson wrote:

>WOW! You haven't been working on this all day, have you?

Both of us :)

>Let me summarize, and see if I've got this straight:
>(1) according to Earnie Boyd (but contradicted by Pierre Humblet) 
[...]
>all of your tests were either CYGWIN=binmode or
>CYGWIN=________, not CYGWIN=nobinmode, you really weren't changing anything 
>here.

Sadly. I should have used nobinmode. I'll try.

>Okay, digging into the stat.t code: You failed tests 18-20 and 26 in stat.t. 
>Tests 18-20 are testing (readable by owner?) (writeable by owner?) and
(executable by
>owner) after doing a chmod 0700. I can't remember if I was building perl 
>under the Administrator account or under my normal NT user account. But,
the "everything
>created by a member of the Administrators group belongs to the group, not 
>the user" NTism may be the culprit here.

Yes, seems to me too, but I thought 'ntea' could solve this (see other
email "'ntea' CHECK please).

>My conclusions are the same as yours:
>    (1) Earnie is right ==> binmode has no effect
>    (2) binary mounted / text mounted don't affect the build, only the runtime
>behavior and tests. Why is another question.

OK for me at this time (+ a free headache).


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Sebastien Barre wrote:

> At 15:07 06/03/99 -0500, Charles Wilson wrote:
>
> (some solutions, and some new problems regarding installation (new patch ?)
> and Modules)
>

WOW! You haven't been working on this all day, have you?

Let me summarize, and see if I've got this straight:
(1) according to Earnie Boyd (but contradicted by Pierre Humblet) CYGWIN=binmode
should have no effect. Two contradictory authorities, hmmm...we'll call this one an
open question. However, since CYGWIN=binmode is the default (?? - geez, I'm not
sure of *anything* anymore) and all of your tests were either CYGWIN=binmode or
CYGWIN=________, not CYGWIN=nobinmode, you really weren't changing anything here.
So, we'll throw that variable out.

(2) Text-mounted build, text-mounted tests, CYGWIN=__________. test results
(abbreviated version)

9 tests skipped, plus 20 subtests skipped.
Failed 7/186 test scripts, 96.24% okay. 39/6193 subtests failed, 99.37% okay.

(3) Text-mounted build, text-mounted tests, CYGWIN=ntea. test results

> 10 tests skipped, plus 20 subtests skipped.
> Failed 6/186 test scripts, 96.77% okay. 33/6191 subtests failed, 99.47% okay.

(4) Text-mounted build, binary-mounted test, CYGWIN=ntea binmode. test results

> 10 tests skipped, plus 20 subtests skipped.
> Failed 4/186 test scripts, 97.85% okay. 11/6191 subtests failed, 99.82% okay.
>
> Bingo ! This is similar to you, except for this test (yours) :
>
> op/stat.t                    58    2   3.45%  4, 35
>

Okay, digging into the stat.t code: You failed tests 18-20 and 26 in stat.t.  Tests
18-20 are testing (readable by owner?) (writeable by owner?) and (executable by
owner) after doing a chmod 0700. I can't remember if I was building perl under the
Administrator account or under my normal NT user account. But, the "everything
created by a member of the Administrators group belongs to the group, not the user"
NTism may be the culprit here.

Test 26 is testing (I just wrote this file. Do I own it?). Again, probably that
ugly NTism.

So, here's another item for the build-kit: {Do / Don't} build as an member of
Administrators group.

(5) Binary-mounted build, binary-mounted test, CYGWIN=ntea binmode.

So, you set ntea, (and binmode....), mounted everything binary, applied the
patches, and *rebuilt.* Rebuild was successful, and the test had similar (NOT
identical) results to (4) above. stat.t failed on tests "*2*, 18-20, 26, 35", not
"*4*, 18-20, 26, 35". Okay, what's the difference between tests 2 and 4? Well, I
don't completely understand them, but they seem to be comparing file-creation times
and file-modified times. I don't really get it. ????

> 10 tests skipped, plus 20 subtests skipped.
> Failed 4/186 test scripts, 97.85% okay. 11/6191 subtests failed, 99.82% okay.
>
> => which is exactly the same as previously. This means that binary and/or
> text mode *might not* (I'm still wondering)  influence the perl build, only
> it's runtime behaviour, like tests.

I believe you are correct. The only real difference between your original
text-mounted build / binary-mounted tests (with appropriate CYGWIN settings) -- ie.
number (4) -- and mine was the extra failures you got on op/stat.t, which I believe
are due to Administrators group problems.

(6) binary-mounted build, binary mounted test, CYGWIN=ntea
> same results (as (4) and (5)), 4 tests failed !

(7) binary-mounted build, text mounted test, CYGWIN=ntea
>  6 tests failed (same as (3))

(8) binary-mounted build, text mounted test, CYGWIN=ntea binmode
> same as (4) and (5)

My conclusions are the same as yours:
    (1) Earnie is right ==> binmode has no effect
    (2) binary mounted / text mounted don't affect the build, only the runtime
behavior and tests. Why is another question.

=> this seems to highlight your explanation. The sdbm and anydbm script

> open files, and they will fail if these file are opened in text mode ? This
> might be logical if these scripts try to read Unix-text files included in
> the distribution, but is strange if they *create* these files, because
> whatever the mode the translation should work (pb will raise only if
> different text mode collide).

Yup. Very strange. I don't really understand Perl all that well (I built the thing
so I could play with it...) I notice that the "problem" tests, anydbm and sdbm,
"open" the files using a construct like:

print (tie(%h,AnyDBM_File,'Op_dbmx', O_RDWR|O_CREAT, 0640)
    ? "ok 1\n" : "not ok 1\n");

I just assumed that the file-open flags would be passed to an fopen()-like function
directly, but maybe I was wrong...I dunno.

> => I do NOT know what to choose : binary mount and 'nobinmode' in CYGWIN,
> or 'text mount' and 'binmode' in CYGWIN ? For now on, I guess I might
> better mount my cygwin partitions as binary, so that build and tests of
> classical Unix tools might have a better chance to succeed. But I choose
> cygwin32 so that I might use Unix tools on (text) files created with
> Windows software : what shall I do ? For sure, I will have to experiment :
> leaving CYGWIN *without* 'binmode' for the moment, and if it fails, put
> 'binmode' back to CYGWIN... Any advice based on real-life experience ?
>

Well, your experiments show that binmode doesn't matter - besides, it's the
default. The only real issue here is that the CR/LF translation (which should be
invisible to the application ?) doesn't seem to be working properly when you've got
the partition mounted text.

Reply to the rest of your message in a followup (this one's getting way too long.)

--Chuck



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Sebastien wrote:

> New interesting problems :
>
> -------------------------------
> 1) I was unable to install !! (what about you ?)

I had no problems -- BUT I had renamed /usr/bin/install to cyg-install, and copied
Pierre Humblet's install script from
ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/porters/Humblet_Pierre_A/install-cygwin-b20-sh
to /usr/bin/install. This probably doesn't affect the problem you describe below,
but I figured I should include the information.

> > make install
> [...]
> ./perl installperl
> /usr/local/bin is not writable by you
> make: *** [install.perl] Error 2
>
> The error message is located at this line in installperl :
> -w $installbin          || $nonono || die "$installbin is not writable by you\n"
>
> But I'm using 'ntea' and made some unsuccessful 'chmod a+w /usr/local/bin'
> !! This is driving me crazy !!

Call me crazy, but could this be another one of those Adminstrators group NTisms?
(I sound like a broken record, I know, but I've been bitten by this thing many
times)

> I removed the line, and was able to install the perl binaries, libs and
> headers (that also what I did before starting this whole discussion with you).
>
> administrateur [545] /usr/local/src/perl5.005_02$ cd /usr/local/
> administrateur [546] /usr/local$ ll
> total 0
> drwxr-xr-x   2 administ Aucun           0 Mar  7 22:54 bin/
> [...]
>

Look here - you're running as Administrator. Adds a little credence to my theory.
Why don't you try as a normal user? Nope - see below.

> My perl.exe is 966464 bytes long.

Mine is 973294 bytes (unstripped). I just noticed that my perl.exe is owned by
Administrator. Hmmm....it looks like I was running as Admin when I built and
installed. Rats. Another beautiful theory slain by an cold ugly fact.

Administrator: /usr/local/ : ls -l
total 0
drwxr-xr-x   2 administ None            0 Mar  7 00:08 bin

However, the "group" id is None (which in NTspeak really means everybody - no group
restrictions applied). Is that what "Aucun" means (I don't speak French)? I'm just
trying to eliminate variables here...


> -------------------------------
> 2) Perl Modules
>
> Still using binary mount but no 'binmode' in CYGWIN, I tried to build (did
> you too ?) some Perl modules (like DB_File, String-CRC) in /usr/local/src
> (which is binary mounted). These modules produce libraries (CRC.a from
> CRC.xs -> CRC.c for example) and have to be statically linked to perl.exe,
> thus producing a new perl.exe (this is handled automatically by issuing :
> make -f Makefile.aperl inst_perl MAP_TARGET=perl.exe).
>
>   - build fails, with that kind of messages :
> /usr/local/lib/perl5/5.00502/cygwin32/CORE/cw32imp.h:343: warning: this is
> the location of the previous definition
>

Nope, I didn't try this. I just wanted a basic build.

>
> meaning that cw32imp.h is included twice or more. Therefore, I disabled the
> cw32imp.h inclusion from /usr/local/lib/perl5/00502/cygwin32/CORE/perl.h,
> line 1242, and that fixed the problem.
>
> /* Work around some cygwin32 problems with importing global symbols */
> #if defined(CYGWIN32) && defined(DLLIMPORT)
> /*
> #   include "cw32imp.h"
> */
> #endif
>
> I know, this is really a dirty hack, did you notice the same problem, do
> you think that it's worth a patch ? Let's investigate that problem.

The Right Thing is to define a global in cw32imp.h that says "You already included
me, skip the rest of this file" eg

#ifndef CW32IMP
#define CW32IMP
---rest of file
#endif

Cool! I got to say "The Right Thing". I've always wanted to say that.

>  <snip>
>
> administrateur [527] /usr/local/src/String-CRC-1.0$ cat
> blib/arch/auto/String/CRC/extralibs.all
> => it contains (34 bytes) the text '-L/usr/local/lib -ldb' surrounded by a
> blank line and followed by many others.
>
> administrateur [526] /usr/local/src/String-CRC-1.0$ od -x
> blib/arch/auto/String/CRC/extralibs.all
> 0000000 2d0a 2f4c 7375 2f72 6f6c 6163 2f6c 696c
> 0000020 2062 6c2d 6264 0a0d 0a0a 0a0a 0a0a 0a0a
> 0000040 0a0a
> 0000042
>
> Notice the '0a0d' !! But I was using both 'binmode' AND binary mount that
> time, where the hell is this '0a0d' coming from ? ((
>

I don't know. But I suspect one of the scripts in lib/extutils/ is doing the work
of creating the extralibs.ld files when you invoke make -f Makefile.aperl....
Unfortunately these scripts are way beyond my limited perl abilities.

IF you accept that the 0d will be inserted into the file no matter what (I don't,
but you gotta start somewhere) THEN in makes sense that switching to text mounts
will help the linker ignore its presence. The real issue is where is it coming from
in the first place. That, I can't answer. Maybe somebody else??

--Chuck



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 03:07 08/03/99 -0500, Charles Wilson wrote:

>> -------------------------------
>> 1) I was unable to install !! (what about you ?)

>I had no problems -- BUT I had renamed /usr/bin/install to cyg-install, and 
>copied Pierre Humblet's install script from

Let's try. Hum. No, that does not work. 'make install' call a perl script
'installperl'.

>> administrateur [545] /usr/local/src/perl5.005_02$ cd /usr/local/
>> administrateur [546] /usr/local$ ll
>> total 0
>> drwxr-xr-x   2 administ Aucun           0 Mar  7 22:54 bin/
>> [...]

>Look here - you're running as Administrator. Adds a little credence to my 
>theory.

Oh yes, no pb about it, but see my new email about 'ntea', I thought that
might *also* solve problems for directories. Well, I could change the
ownership of /usr/local/bin (*grin*), or apply a patch.


>> -------------------------------
>> 2) Perl Modules
>>
>Nope, I didn't try this. I just wanted a basic build.

Too bad :)

>The Right Thing is to define a global in cw32imp.h that says "You already 
>included me, skip the rest of this file" eg

>#ifndef CW32IMP
>#define CW32IMP
>---rest of file
>#endif

No, sorry, that's not the problem (but indeed cw32imp.h was lacking this
feature). I investigate a bit further, and found that the file was included
once, but it redefined some stuff previously defined in many other headers
:(( You definitely have to exclude this file. That would be nice if you
could try a very simple Module like String-CRC (see CPAN repository).

ftp://ftp.cise.ufl.edu/pub/perl/CPAN/modules/by-module/String/String-CRC-1.0
.tar.gz

% cd String-CRC-1.0
% perl Makefile.PL
% make
% make test


>> Notice the '0a0d' !! But I was using both 'binmode' AND binary mount that
>> time, where the hell is this '0a0d' coming from ? ((

>I don't know. But I suspect one of the scripts in lib/extutils/ is doing the 
>work of creating the extralibs.ld files when you invoke make -f
Makefile.aperl....
>Unfortunately these scripts are way beyond my limited perl abilities.

>will help the linker ignore its presence. The real issue is where is it 
>coming from in the first place. That, I can't answer. Maybe somebody else??

I found it ! SORRY, my fault (once again).

The 'Od' following the "-ld" came from an old module that I compiled for
Perl (DB_File) as I was testing my old Perl build (it was lying around).
And of course, I did that while my partitions where mounted as text ! And
this is where it comes from, as the file was then copied to the obscure
Perl directories, and is now used as part as the concatenation :(

I rebuild it in binary mount mode, and all modules compile perfectly :

=> do not mix modules build in text and binary mount modes !

Well, I guess we are near the end : 2 problems to solve for me 
	- install fail
	- cw32imp.h shall NOT be include

Thanks

P.S. :
Here is summary of what I think about the modules :

Some Perl modules are bundled with .xs files which are translated to .c
format and compiled to produce object files (.o) and/or a library (.a).
These .xs are extensions/stubs that might be useful to speed up functions
or access external libraries/packages. If Perl was built statically, then
these extensions have to be statically linked (added) against perl.exe in
order to produce a new perl.exe which will be reinstalled somewhere
(replacing the old one).

Perl maintains a list of extensions that have been added to the current
perl.exe (that is, all modules except libperl.a). As an extension might
also depend on other libraries (for example, a module might implement a
perl extension to handle the Zlib, and therefore shall refer to -lz), Perl
also stores a list (text file) of additional(extra) libs needed for every
module. This seems to be site specific : for a module M, it might be
located in two places :
     /usr/local/lib/perl5/5.00502/cygwin32/auto/M/extralibs.ld
     /usr/local/lib/perl5/site_perl/cygwin32/auto/M/extralibs.ld

For example, the DB_File module is a Perl extension designed to allow
anyone to use the Berkeley DB library (which have to be build separately).
Its extralibs.ld might be '-L/usr/local/lib -ldb' (notice the -ldb).

Note : this /usr/local/lib/perl5/site_perl/cygwin32/auto/M/ will also store
the extensions itself (.a) useful to rebuild the whole perl.exe.

After building/testing/installing an extension module you might update the
new perl.exe by issuing in the module directory :

> make -f Makefile.aperl inst_perl MAP_TARGET=perl.exe

This step will build a new perl.exe by compiling a classical perlmain.c
file, statically link it to libperl.a, to ALL previous extensions (.a
stored in cygwin32/auto/M/), to usual libraries (-lcygwin -lm, etc.) AND to
all extralibs. The list of all extralibs is computed by concatenating (cat)
all extralibs.ld (for every known extensions + the current one), leading to
an extralibs.all file, which is used.

BEWARE of your mount mode. If you compiled some modules on text mounted
partitions, the extralibs.ld file will store very nasty '0d' bytes related
to the way Windows handle text file ('\n' are translated to'0a0d' instead
of 'Oa' in Unix world). If you switch to binary mount mode, the previously
described process will FAIL because the linker will crash on '0d' in
extralibs.all : in binary mode, it will not understand that 'OaOd' might be
swallowed together, it will just swallow 'Oa', thus leaving the 'Od'.



______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 03:07 08/03/99 -0500, Charles Wilson wrote:

>> -------------------------------
>> 1) I was unable to install !! (what about you ?)

>I had no problems -- BUT I had renamed /usr/bin/install to cyg-install, and 
>copied Pierre Humblet's install script from

Let's try. Hum. No, that does not work. 'make install' call a perl script
'installperl'.

>> administrateur [545] /usr/local/src/perl5.005_02$ cd /usr/local/
>> administrateur [546] /usr/local$ ll
>> total 0
>> drwxr-xr-x   2 administ Aucun           0 Mar  7 22:54 bin/
>> [...]

>Look here - you're running as Administrator. Adds a little credence to my 
>theory.

Oh yes, no pb about it, but see my new email about 'ntea', I thought that
might *also* solve problems for directories. Well, I could change the
ownership of /usr/local/bin (*grin*), or apply a patch.


>> -------------------------------
>> 2) Perl Modules
>>
>Nope, I didn't try this. I just wanted a basic build.

Too bad :)

>The Right Thing is to define a global in cw32imp.h that says "You already 
>included me, skip the rest of this file" eg

>#ifndef CW32IMP
>#define CW32IMP
>---rest of file
>#endif

No, sorry, that's not the problem (but indeed cw32imp.h was lacking this
feature). I investigate a bit further, and found that the file was included
once, but it redefined some stuff previously defined in many other headers
:(( You definitely have to exclude this file. That would be nice if you
could try a very simple Module like String-CRC (see CPAN repository).

ftp://ftp.cise.ufl.edu/pub/perl/CPAN/modules/by-module/String/String-CRC-1.0
.tar.gz

% cd String-CRC-1.0
% perl Makefile.PL
% make
% make test


>> Notice the '0a0d' !! But I was using both 'binmode' AND binary mount that
>> time, where the hell is this '0a0d' coming from ? ((

>I don't know. But I suspect one of the scripts in lib/extutils/ is doing the 
>work of creating the extralibs.ld files when you invoke make -f
Makefile.aperl....
>Unfortunately these scripts are way beyond my limited perl abilities.

>will help the linker ignore its presence. The real issue is where is it 
>coming from in the first place. That, I can't answer. Maybe somebody else??

I found it ! SORRY, my fault (once again).

The 'Od' following the "-ld" came from an old module that I compiled for
Perl (DB_File) as I was testing my old Perl build (it was lying around).
And of course, I did that while my partitions where mounted as text ! And
this is where it comes from, as the file was then copied to the obscure
Perl directories, and is now used as part as the concatenation :(

I rebuild it in binary mount mode, and all modules compile perfectly :

=> do not mix modules build in text and binary mount modes !

Well, I guess we are near the end : 2 problems to solve for me 
	- install fail
	- cw32imp.h shall NOT be include

Thanks

P.S. :
Here is summary of what I think about the modules :

Some Perl modules are bundled with .xs files which are translated to .c
format and compiled to produce object files (.o) and/or a library (.a).
These .xs are extensions/stubs that might be useful to speed up functions
or access external libraries/packages. If Perl was built statically, then
these extensions have to be statically linked (added) against perl.exe in
order to produce a new perl.exe which will be reinstalled somewhere
(replacing the old one).

Perl maintains a list of extensions that have been added to the current
perl.exe (that is, all modules except libperl.a). As an extension might
also depend on other libraries (for example, a module might implement a
perl extension to handle the Zlib, and therefore shall refer to -lz), Perl
also stores a list (text file) of additional(extra) libs needed for every
module. This seems to be site specific : for a module M, it might be
located in two places :
     /usr/local/lib/perl5/5.00502/cygwin32/auto/M/extralibs.ld
     /usr/local/lib/perl5/site_perl/cygwin32/auto/M/extralibs.ld

For example, the DB_File module is a Perl extension designed to allow
anyone to use the Berkeley DB library (which have to be build separately).
Its extralibs.ld might be '-L/usr/local/lib -ldb' (notice the -ldb).

Note : this /usr/local/lib/perl5/site_perl/cygwin32/auto/M/ will also store
the extensions itself (.a) useful to rebuild the whole perl.exe.

After building/testing/installing an extension module you might update the
new perl.exe by issuing in the module directory :

> make -f Makefile.aperl inst_perl MAP_TARGET=perl.exe

This step will build a new perl.exe by compiling a classical perlmain.c
file, statically link it to libperl.a, to ALL previous extensions (.a
stored in cygwin32/auto/M/), to usual libraries (-lcygwin -lm, etc.) AND to
all extralibs. The list of all extralibs is computed by concatenating (cat)
all extralibs.ld (for every known extensions + the current one), leading to
an extralibs.all file, which is used.

BEWARE of your mount mode. If you compiled some modules on text mounted
partitions, the extralibs.ld file will store very nasty '0d' bytes related
to the way Windows handle text file ('\n' are translated to'0a0d' instead
of 'Oa' in Unix world). If you switch to binary mount mode, the previously
described process will FAIL because the linker will crash on '0d' in
extralibs.all : in binary mode, it will not understand that 'OaOd' might be
swallowed together, it will just swallow 'Oa', thus leaving the 'Od'.



______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Sebastien wrote:

> New interesting problems :
>
> -------------------------------
> 1) I was unable to install !! (what about you ?)

I had no problems -- BUT I had renamed /usr/bin/install to cyg-install, and copied
Pierre Humblet's install script from
ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/porters/Humblet_Pierre_A/install-cygwin-b20-sh
to /usr/bin/install. This probably doesn't affect the problem you describe below,
but I figured I should include the information.

> > make install
> [...]
> ./perl installperl
> /usr/local/bin is not writable by you
> make: *** [install.perl] Error 2
>
> The error message is located at this line in installperl :
> -w $installbin          || $nonono || die "$installbin is not writable by you\n"
>
> But I'm using 'ntea' and made some unsuccessful 'chmod a+w /usr/local/bin'
> !! This is driving me crazy !!

Call me crazy, but could this be another one of those Adminstrators group NTisms?
(I sound like a broken record, I know, but I've been bitten by this thing many
times)

> I removed the line, and was able to install the perl binaries, libs and
> headers (that also what I did before starting this whole discussion with you).
>
> administrateur [545] /usr/local/src/perl5.005_02$ cd /usr/local/
> administrateur [546] /usr/local$ ll
> total 0
> drwxr-xr-x   2 administ Aucun           0 Mar  7 22:54 bin/
> [...]
>

Look here - you're running as Administrator. Adds a little credence to my theory.
Why don't you try as a normal user? Nope - see below.

> My perl.exe is 966464 bytes long.

Mine is 973294 bytes (unstripped). I just noticed that my perl.exe is owned by
Administrator. Hmmm....it looks like I was running as Admin when I built and
installed. Rats. Another beautiful theory slain by an cold ugly fact.

Administrator: /usr/local/ : ls -l
total 0
drwxr-xr-x   2 administ None            0 Mar  7 00:08 bin

However, the "group" id is None (which in NTspeak really means everybody - no group
restrictions applied). Is that what "Aucun" means (I don't speak French)? I'm just
trying to eliminate variables here...


> -------------------------------
> 2) Perl Modules
>
> Still using binary mount but no 'binmode' in CYGWIN, I tried to build (did
> you too ?) some Perl modules (like DB_File, String-CRC) in /usr/local/src
> (which is binary mounted). These modules produce libraries (CRC.a from
> CRC.xs -> CRC.c for example) and have to be statically linked to perl.exe,
> thus producing a new perl.exe (this is handled automatically by issuing :
> make -f Makefile.aperl inst_perl MAP_TARGET=perl.exe).
>
>   - build fails, with that kind of messages :
> /usr/local/lib/perl5/5.00502/cygwin32/CORE/cw32imp.h:343: warning: this is
> the location of the previous definition
>

Nope, I didn't try this. I just wanted a basic build.

>
> meaning that cw32imp.h is included twice or more. Therefore, I disabled the
> cw32imp.h inclusion from /usr/local/lib/perl5/00502/cygwin32/CORE/perl.h,
> line 1242, and that fixed the problem.
>
> /* Work around some cygwin32 problems with importing global symbols */
> #if defined(CYGWIN32) && defined(DLLIMPORT)
> /*
> #   include "cw32imp.h"
> */
> #endif
>
> I know, this is really a dirty hack, did you notice the same problem, do
> you think that it's worth a patch ? Let's investigate that problem.

The Right Thing is to define a global in cw32imp.h that says "You already included
me, skip the rest of this file" eg

#ifndef CW32IMP
#define CW32IMP
---rest of file
#endif

Cool! I got to say "The Right Thing". I've always wanted to say that.

>  <snip>
>
> administrateur [527] /usr/local/src/String-CRC-1.0$ cat
> blib/arch/auto/String/CRC/extralibs.all
> => it contains (34 bytes) the text '-L/usr/local/lib -ldb' surrounded by a
> blank line and followed by many others.
>
> administrateur [526] /usr/local/src/String-CRC-1.0$ od -x
> blib/arch/auto/String/CRC/extralibs.all
> 0000000 2d0a 2f4c 7375 2f72 6f6c 6163 2f6c 696c
> 0000020 2062 6c2d 6264 0a0d 0a0a 0a0a 0a0a 0a0a
> 0000040 0a0a
> 0000042
>
> Notice the '0a0d' !! But I was using both 'binmode' AND binary mount that
> time, where the hell is this '0a0d' coming from ? ((
>

I don't know. But I suspect one of the scripts in lib/extutils/ is doing the work
of creating the extralibs.ld files when you invoke make -f Makefile.aperl....
Unfortunately these scripts are way beyond my limited perl abilities.

IF you accept that the 0d will be inserted into the file no matter what (I don't,
but you gotta start somewhere) THEN in makes sense that switching to text mounts
will help the linker ignore its presence. The real issue is where is it coming from
in the first place. That, I can't answer. Maybe somebody else??

--Chuck



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 15:07 06/03/99 -0500, Charles Wilson wrote:

(some solutions, and some new problems regarding installation (new patch ?)
and Modules)


>Here's the three tests that failed for Sebastien but worked for me:
>
>fs.t  FAILED tests 5,7,9,10
>    each of these are testing access using stat(). I've got CYGWIN=ntea,
>I'm guessing that Sebastien doesn't. Here is a representative part of
>fs.t:

That's perfectly right, I was not using 'ntea' ! thanks to all of you for
this fix.
=> another information that might be worth adding to your build instructions :)

Here is the new result, *without* rebuilding perl :

Failed 6 test scripts out of 186, 91.40% okay.

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/anydbm.t      2   512    12    8  66.67%  5-12
lib/findbin.t                 1    1 100.00%  1
lib/sdbm.t        2   512    18   14  77.78%  5-18
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  2, 18-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 20 subtests skipped.
Failed 6/186 test scripts, 96.77% okay. 33/6191 subtests failed, 99.47% okay.

>sdbm.t  FAILED test 2, 5-18
>    test 2 seems similar to the stat() problems above.
>    tests 5-18 seem to involve a hashtable written to a file (I think),
>and the behavior of that hashtable is then tested. If the file is on a
>text mount, and but is opened in O_BINARY mode (ie. due to the
>USEMYBINMODE  patch) then you get problems?

>anydbm.t FAILED test 2, 5-12
>    test 2 is another stat() problem
>    tests 5-12 are similar to the the failed tests in sdbm.t.

All right, let's have a look at this binary problem. My files are on a text
mount, let's put all my partitions in binary mode, add 'binmode' to CYGWIN,
and launch the test (without rebuilding perl) :

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/findbin.t                 1    1 100.00%  1
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  4, 18-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 20 subtests skipped.
Failed 4/186 test scripts, 97.85% okay. 11/6191 subtests failed, 99.82% okay.

Bingo ! This is similar to you, except for this test (yours) :

op/stat.t                    58    2   3.45%  4, 35

I said that I did not use binary partitions because I had problem while
building Perl. Let's try again with this 'ntea' stuff set, and all your
patches : Perl build successfully this time (binary mount, 'binmode' in
CYGWIN).

Failed 4 test scripts out of 186, 92.47% okay.

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/findbin.t                 1    1 100.00%  1
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  2, 18-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 20 subtests skipped.
Failed 4/186 test scripts, 97.85% okay. 11/6191 subtests failed, 99.82% okay.

=> which is exactly the same as previously. This means that binary and/or
text mode *might not* (I'm still wondering)  influence the perl build, only
it's runtime behaviour, like tests.

Let's play :

no 'binmode' in CYGWIN + binary mount : same results, 4 tests failed !
no 'binmode' in CYGWIN + text mount : 6 tests failed (logical as it matchs
the beginning of this mail)
'binmode'  in CYGWIN + text mount : 4 tests failed (see above).

=> this seems to highlight your explanation. The sdbm and anydbm script
open files, and they will fail if these file are opened in text mode ? This
might be logical if these scripts try to read Unix-text files included in
the distribution, but is strange if they *create* these files, because
whatever the mode the translation should work (pb will raise only if
different text mode collide).

=> I do NOT know what to choose : binary mount and 'nobinmode' in CYGWIN,
or 'text mount' and 'binmode' in CYGWIN ? For now on, I guess I might
better mount my cygwin partitions as binary, so that build and tests of
classical Unix tools might have a better chance to succeed. But I choose
cygwin32 so that I might use Unix tools on (text) files created with
Windows software : what shall I do ? For sure, I will have to experiment :
leaving CYGWIN *without* 'binmode' for the moment, and if it fails, put
'binmode' back to CYGWIN... Any advice based on real-life experience ?

New interesting problems : 

-------------------------------
1) I was unable to install !! (what about you ?)

> make install
[...]
./perl installperl
/usr/local/bin is not writable by you
make: *** [install.perl] Error 2

The error message is located at this line in installperl :
-w $installbin		|| $nonono || die "$installbin is not writable by you\n"

But I'm using 'ntea' and made some unsuccessful 'chmod a+w /usr/local/bin'
!! This is driving me crazy !! 

I removed the line, and was able to install the perl binaries, libs and
headers (that also what I did before starting this whole discussion with you).

administrateur [545] /usr/local/src/perl5.005_02$ cd /usr/local/
administrateur [546] /usr/local$ ll
total 0
drwxr-xr-x   2 administ Aucun           0 Mar  7 22:54 bin/
[...]

My perl.exe is 966464 bytes long.

-------------------------------
2) Perl Modules 

Still using binary mount but no 'binmode' in CYGWIN, I tried to build (did
you too ?) some Perl modules (like DB_File, String-CRC) in /usr/local/src
(which is binary mounted). These modules produce libraries (CRC.a from
CRC.xs -> CRC.c for example) and have to be statically linked to perl.exe,
thus producing a new perl.exe (this is handled automatically by issuing :
make -f Makefile.aperl inst_perl MAP_TARGET=perl.exe).

  - build fails, with that kind of messages :
/usr/local/lib/perl5/5.00502/cygwin32/CORE/cw32imp.h:343: warning: this is
the location of the previous definition

meaning that cw32imp.h is included twice or more. Therefore, I disabled the
cw32imp.h inclusion from /usr/local/lib/perl5/00502/cygwin32/CORE/perl.h,
line 1242, and that fixed the problem. 

/* Work around some cygwin32 problems with importing global symbols */
#if defined(CYGWIN32) && defined(DLLIMPORT) 
/*
#   include "cw32imp.h"
*/
#endif

I know, this is really a dirty hack, did you notice the same problem, do
you think that it's worth a patch ? Let's investigate that problem.

 - test fails :
administrateur [600] /usr/local/src/String-CRC-1.0$ make test
[...]
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/B/extralibs
.ld >> blib/arch/auto/String/CRC/extralibs.all
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/DB_File/ext
ralibs.ld >> blib/arch/auto/String/CRC/extralibs.all
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Data/Dumper
/extralibs.ld >> blib/arch/auto/String/CRC/extralibs.all
[...]
gcc2 -L/usr/local/lib -o perl -O ./perlmain.o
blib/arch/auto/String/CRC/CRC.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/re/re.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/attrs/attrs
.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Socket/Sock
et.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/SDBM_File/S
DBM_File.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Opcode/Opco
de.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/IO/IO.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Fcntl/Fcntl
.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/DynaLoader/
DynaLoader.a

/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/Data/Dumper
/Dumper.a
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/DB_File/DB_
File.a /d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/B/B.a
 /usr/local/lib/perl5/5.00502/cygwin32/CORE/libperl.a `cat
blib/arch/auto/String/CRC/extralibs.all` -lcygwin -lm -lc -lkernel32
/d/devel/gnuwin32/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld: cannot
open -
: No such file or directory
collect2: ld returned 1 exit status
make[1]: *** [perl] Error 1
make: *** [perl] Error 2


Playing with text mount, or 'binmode' in CYGWIN did not help. This error
was also reproducible with other modules... Package were extracted with tar
and gzip.

There is a suspicious 'cat' at the end of the gcc2 command. Seems to me
that there is an empty thing (or carriage return) in the extralibs.all that
produce the 'cannot open - <CR/LF> : No such file or directory'. Let's have
a look at it :

administrateur [527] /usr/local/src/String-CRC-1.0$ cat
blib/arch/auto/String/CRC/extralibs.all
=> it contains (34 bytes) the text '-L/usr/local/lib -ldb' surrounded by a
blank line and followed by many others.

administrateur [526] /usr/local/src/String-CRC-1.0$ od -x
blib/arch/auto/String/CRC/extralibs.all
0000000 2d0a 2f4c 7375 2f72 6f6c 6163 2f6c 696c
0000020 2062 6c2d 6264 0a0d 0a0a 0a0a 0a0a 0a0a
0000040 0a0a
0000042

Notice the '0a0d' !! But I was using both 'binmode' AND binary mount that
time, where the hell is this '0a0d' coming from ? (( 

That's *so* weird, I had NO problem to get rid of this module with my
previous Perl build and partitions mounted as text. Let's try again by
removing 'binmode' from my CYGWIN, and putting my partitions back to text
mode ! 

=> IT WORKS (noooooooo way). All tests successfull. What about
extralibs.all this time :

administrateur [527] /usr/local/src/String-CRC-1.0$ cat
blib/arch/auto/String/CRC/extralibs.all
=> it contains (*45* bytes) the text '-L/usr/local/lib -ldb' surrounded by
a blank line and followed by many others.

administrateur [526] /usr/local/src/String-CRC-1.0$ od -x
blib/arch/auto/String/CRC/extralibs.all
0000000 0a0d 4c2d 752f 7273 6c2f 636f 6c61 6c2f
0000020 6269 2d20 646c 0d62 0d0a 0d0a 0d0a 0d0a
0000040 0d0a 0d0a 0d0a 0d0a 0d0a 0d0a 000a
0000055

Notice this time that every '0a0d' works in 'pair' (they will be
'swallowed' as empty lines).

=> that explain the previous error message in binary mode : the linker
bumped on the 'Od', which was surrounded by 'Oa'
/d/devel/gnuwin32/cygwin-b20/H-i586-cygwin32/i586-cygwin32/bin/ld: cannot
open -
: No such file or directory

Let's examine blib/arch/auto/String/CRC/extralibs.all more carefully (I'm
not a perl guru). It's build during 'make test' :

administrateur [600] /usr/local/src/String-CRC-1.0$ make test
[...]
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/B/extralibs
.ld >> blib/arch/auto/String/CRC/extralibs.all
cat
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/DB_File/ext
ralibs.ld >> blib/arch/auto/String/CRC/extralibs.all

It seems to be the concatenation of information regarding previously
installed modules.  I looked at
/d/devel/gnuwin32/root/usr/local/lib/perl5/5.00502/cygwin32/auto/*/extralibs
.ld, and ALL files are 1 bytes long, and this byte is... '0a", which
explains this row of 'Oa' at the end of extralibs.all.

I still do not know where this 'Od' comes from... 

Any help ?

______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Earnie Boyd wrote:

> ---Charles Wilson <cwilson@ee.gatech.edu> wrote:
> 8<
> > Now, all three of your patches address problems I didn't see; the
> main difference
> > between us being binary vs. text mounts. If that is the case, should
> these tests
> > be skipped for all cygwin (binary and text mount) or should the
> tests be fixed so
> > that they work for both binary and text mounts? I'm not sure if the
> second option
> > means hacking the test scripts, or hacking perl itself.
> >
> 8<
>
> IMHO, it seems that the easiest fix for this would be for perl to
> always open a script file in text mode processing.  Any file that can
> be potentially created by a human with an editor should be opened for
> text mode processing.

The issue is that the scripts in question directly open files themselves,
specifying O_RDWR | O_CREAT, etc. and test access to those files using
stat(). Thus the problem in these cases seem to be the scripts (and the
CYGWIN=ntea variable), not the perl exec itself.

Here's the three tests that failed for Sebastien but worked for me:

fs.t  FAILED tests 5,7,9,10
    each of these are testing access using stat(). I've got CYGWIN=ntea,
I'm guessing that Sebastien doesn't. Here is a representative part of
fs.t:

($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime,
    $blksize,$blocks) = stat('c');
if ($Is_Dosish) {print "ok 7 # skipped: no link\n";}
elsif (($mode & 0777) == 0777) {print "ok 7\n";}
else {print "not ok 7\n";}

sdbm.t  FAILED test 2, 5-18
    test 2 seems similar to the stat() problems above.
    tests 5-18 seem to involve a hashtable written to a file (I think),
and the behavior of that hashtable is then tested. If the file is on a
text mount, and but is opened in O_BINARY mode (ie. due to the
USEMYBINMODE  patch) then you get problems?

anydbm.t FAILED test 2, 5-12
    test 2 is another stat() problem
    tests 5-12 are similar to the the failed tests in sdbm.t.

Sebastien - try setting ntea and building perl again - but watch out for
those eadata files. Setting ntea, and using only my patch (not your
changes) should get rid of the failures in fs.t, and the failures of
test2 in sdbm and anydbm. At least, that's my guess.


--Chuck





--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Earnie Boyd]

---Charles Wilson <cwilson@ee.gatech.edu> wrote:
8<
> Now, all three of your patches address problems I didn't see; the
main difference
> between us being binary vs. text mounts. If that is the case, should
these tests
> be skipped for all cygwin (binary and text mount) or should the
tests be fixed so
> that they work for both binary and text mounts? I'm not sure if the
second option
> means hacking the test scripts, or hacking perl itself.
> 
8<

IMHO, it seems that the easiest fix for this would be for perl to
always open a script file in text mode processing.  Any file that can
be potentially created by a human with an editor should be opened for
text mode processing.
==
-                        \\||//
-------------------o0O0--Earnie--0O0o-------------------
--                earnie_boyd@yahoo.com               --
-- http://www.freeyellow.com/members5/gw32/index.html --
----------------------ooo0O--O0ooo----------------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Steven Zeil]

I compiled the 5.005_002 source distribution from CPAN with little difficulty.
The result seems to work well enough for the fairly simple scripts that I use on
a regular basis.

The README.cygwin32 file included with the distribution pretty much steps
through it.  The only deviation I recall is that, before doing step 4 (sh
configure), I found that I needed to edit the various paths in the
hints/cygwin32.sh file to tell it where my cygwin32 installation resided.   With
those changes, I just let configure use its defaults wherever possible.

Steve Zeil



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Steven Zeil]

I compiled the 5.005_002 source distribution from CPAN with little difficulty.
The result seems to work well enough for the fairly simple scripts that I use on
a regular basis.

The README.cygwin32 file included with the distribution pretty much steps
through it.  The only deviation I recall is that, before doing step 4 (sh
configure), I found that I needed to edit the various paths in the
hints/cygwin32.sh file to tell it where my cygwin32 installation resided.   With
those changes, I just let configure use its defaults wherever possible.

Steve Zeil



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Compiling Perl under b20.1

[Allan Peda]

Has there been much success with this?  I've done it with MSVC + nmake,
but I'd get more of a thrill using cygwin.

I searched at www.qub.com, but it doesn't look too active.  The
directory entry in the distribution with cygwin instructions didn't work
well for me last time I tried.

Allan

A


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 22:04 04/03/99 -0500, Allan Peda wrote:

>Has there been much success with this?  I've done it with MSVC + nmake,
>but I'd get more of a thrill using cygwin.

I did (5.005_002  static build, 91.4% successfull test).

As many people from this list helped me, I'd glad to offer the same. 

Basically, 

*) Read the README.cywin32

*) Edit the hints/cygwin32.sh file to reflect your paths.

Here are also a couple of settings I found useful when performing automatic
build (copy hints/cygwin32.sh to config.sh, and do sh Configure -d)

usedl='n'
i_stdarg='define'
i_varargs='undef'
osname='cygwin_nt-4.0'
osvers='20.1'
archname='cygwin32'
signal_t='int'
d_voidsig='define'
i_sysselct='undef'
signal_t='void'

*) Browse Usenet archives (DejaNews), and find  "HOWTO: Builiding Perl
under Win95/98 using Cygwin32 " 
Steven Morlock <newspost@morlock.net>
1998/12/21
comp.lang.perl.misc

*) Then apply this patch (Thanks to Todd Goodman)

This is my change in Cwd.pm:
--- cwd.pm	Fri Feb 26 21:52:42 1999
+++ cwd.pm.orig	Fri Jan 22 20:49:54 1999
@@ -208,8 +208,6 @@
     my $start = @_ ? shift : '.';
     my($dotdots, $cwd, @pst, @cst, $dir, @tst);
 
-    return cwd() if ( $^O =~ /cygwin/ );
-
     unless (@cst = stat( $start ))
     {

And tell me (email) if it fails.

______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

I've taken Sebastien Barre's suggestions and Steven Morlock's instructions and
successfully compiled perl5.005_02 under Cygwin B20.1 and WinNT4sp4. I took
all their suggestions and created a patch file and collected the instructions
together in the attached package (6kB). It can also be downloaded from

ftp://belgarion.resnet.gatech.edu/pub/cygwin/B20/perl-cygwin-instructions.tar.gz

Yoiu can also find a binary distribution of perl at the same location:

ftp://belgarion.resnet.gatech.edu/pub/cygwin/B20/perl5.005_02-cygwinb20.tar.bz2

It's 2.6Meg, unpack from /. It will install into /usr/local/bin/,
/usr/local/man/, /usr/local/lib/, and a few text files into
/usr/local/src/perl5.005_02/. The ftp server has been up & down a lot lately,
please be patient.

Please comment on both the collected build instructions and the binary
distribution.

Thanks,
Chuck Wilson

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 16:13 05/03/99 -0500, Charles Wilson wrote:

>I've taken Sebastien Barre's suggestions and Steven Morlock's instructions and
>successfully compiled perl5.005_02 under Cygwin B20.1 and WinNT4sp4. I took
>all their suggestions and created a patch file and collected the instructions
>together in the attached package (6kB).

Very good, thanks !. I tested it, and it works. After applying the patch,
one might have to change his paths in hints/cygwin32.sh, otherwise it's
perfect.

>Please comment on both the collected build instructions and the binary
>distribution.

*) Steven Morlock  published TWO articles (a correction to the first one),
but you did not include the second one (which is related to binary mode). 

Re: HOWTO: Builiding Perl under Win95/98 using Cygwin32  
Author: Steven Morlock <newspost@morlock.net>
Date: 1998/12/22
Forum: comp.lang.perl.misc 

It's not that important because you included the modification in your patch :

+ #if defined(__CYGWIN32__)
+   /* USEMYBINMODE
...

*) I also forgot to mention this article :

     To: cygwin@sourceware.cygnus.com 
     Subject: configure and cpp problem (Was: bug: missing include files in
B20.1) 
     From: Teun Burgers <burgers@ecn.nl> 
     Date: Mon, 22 Feb 1999 16:52:09 +0100 

But I seems to me the one DO NOT need it (but I kept it, just in case). You
might have a look anyway.

*) Furthermore, I'd just add that I had some problems while building perl
if source files were extracted in a binary mounted partition. BUT I also
read some testimony regarding the contrary (i.e. you need to mount it as
binary) ! Therefore, It's just a hint, but if you experience some problems
(sadly, I forgot to save the error messages), try different mount mode.

*) make test

Here is the result after applying your modifications :

> make test
Failed 7 test scripts out of 186, 91.40% okay.

>cd t
>perl harness

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
io/fs.t                      26    4  15.38%  5, 7, 9-10
lib/anydbm.t      2   512    12    9  75.00%  2, 5-12
lib/findbin.t                 1    1 100.00%  1
lib/sdbm.t        2   512    18   15  83.33%  2, 5-18
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  2, 9, 19-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
9 tests skipped, plus 20 subtests skipped.
Failed 7/186 test scripts, 96.24% okay. 39/6193 subtests failed, 99.37% okay.

(anydbm and sdbm might be different if you mounted your partition as binary).

Some of them just fail because they should NOT be executed in a win32
implementation. They should be skipped. Sadly, the test behind this does
NOT handle cygwin32 environment, just plain MS32 by comparing OS name to
MSWin32 ($^O eq 'MSWin32'). Let's add a test for cygwin ($^O =~ /cygwin/).
Here is a couple of tests I think that might be patched (I could not do
anything for magic.t, as well as stat.t, which is a known problem) :

diff -urN perl5.005_02/t/io/fs.t.orig perl5.005_02/t/io/fs.t
--- perl5.005_02/t/io/fs.t.orig	Sat Mar 06 12:18:26 1999
+++ perl5.005_02/t/io/fs.t	Sat Mar 06 12:18:31 1999
@@ -12,7 +12,7 @@
 $Is_Dosish = ($^O eq 'dos' or $^O eq 'os2');
 
 # avoid win32 (for now)
-do { print "1..0\n"; exit(0); } if $^O eq 'MSWin32';
+do { print "1..0\n"; exit(0); } if $^O eq 'MSWin32' || $^O =~ /cygwin/;
 
 print "1..26\n";
 
diff -urN perl5.005_02/t/lib/anydbm.t.orig perl5.005_02/t/lib/anydbm.t
--- perl5.005_02/t/lib/anydbm.t.orig	Sat Mar 06 12:22:30 1999
+++ perl5.005_02/t/lib/anydbm.t	Sat Mar 06 12:23:04 1999
@@ -22,7 +22,7 @@
 if (! -e $Dfile) {
 	($Dfile) = <Op_dbmx*>;
 }
-if ($^O eq 'amigaos' || $^O eq 'os2' || $^O eq 'MSWin32' || $^O eq 'dos') {
+if ($^O eq 'amigaos' || $^O eq 'os2' || $^O eq 'MSWin32' || $^O eq 'dos'
|| $^O =~ /cygwin/) {
     print "ok 2 # Skipped: different file permission semantics\n";
 }
 else {
diff -urN perl5.005_02/t/lib/sdbm.t.orig perl5.005_02/t/lib/sdbm.t
--- perl5.005_02/t/lib/sdbm.t.orig	Sat Mar 06 12:27:04 1999
+++ perl5.005_02/t/lib/sdbm.t	Sat Mar 06 12:27:10 1999
@@ -27,7 +27,7 @@
 if (! -e $Dfile) {
 	($Dfile) = <Op_dbmx.*>;
 }
-if ($^O eq 'amigaos' || $^O eq 'os2' || $^O eq 'MSWin32' || $^O eq 'dos') {
+if ($^O eq 'amigaos' || $^O eq 'os2' || $^O eq 'MSWin32' || $^O eq 'dos'
|| $^O =~ /cygwin/) {
     print "ok 2 # Skipped: different file permission semantics\n";
 }
 else {


(these patch might be just added to your perl.patch and used with patch -p1).

> make test
Failed 6 test scripts out of 186, 91.40% okay.

> cd t
> perl harness

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/anydbm.t      2   512    12    8  66.67%  5-12
lib/findbin.t                 1    1 100.00%  1
lib/sdbm.t        2   512    18   14  77.78%  5-18
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  2, 9, 19-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 22 subtests skipped.
Failed 6/186 test scripts, 96.77% okay. 33/6167 subtests failed, 99.46% okay.

Which is slightly better :)

Hope it helps


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Sebastien Barre wrote:

> Very good, thanks !. I tested it, and it works. After applying the patch,
> one might have to change his paths in hints/cygwin32.sh, otherwise it's
> perfect.

Yeah, that's true. The "build-instructions" were more in the nature of "here's how
I built the binary kit" than a general guide. BTW, did you apply the patch to a
pristine copy of the source, or had you already applied the changes from Teun
Burgers (below)?

> >Please comment on both the collected build instructions and the binary
> >distribution.
>
> *) Steven Morlock  published TWO articles (a correction to the first one),
> but you did not include the second one (which is related to binary mode).
>
> Re: HOWTO: Builiding Perl under Win95/98 using Cygwin32
> Author: Steven Morlock <newspost@morlock.net>
> Date: 1998/12/22
> Forum: comp.lang.perl.misc
>
> It's not that important because you included the modification in your patch :
>
> + #if defined(__CYGWIN32__)
> +   /* USEMYBINMODE
> ...

Oops. I'll go grab that usenet posting and stick it in the build instruction kit.

> *) I also forgot to mention this article :
>
>      To: cygwin@sourceware.cygnus.com
>      Subject: configure and cpp problem (Was: bug: missing include files in
> B20.1)
>      From: Teun Burgers <burgers@ecn.nl>
>      Date: Mon, 22 Feb 1999 16:52:09 +0100
>
> But I seems to me the one DO NOT need it (but I kept it, just in case). You
> might have a look anyway.

Hmmm....here's the relevant part of Teun Burgers' post:

> The configure script (relevant part in fhdr.old) creates
> a script findhdr that looks for the header file. findhr first
> simply tests for existance (test -f) of the .h file in
> H-i586-cygwin32/i586-cygwin32/include and if not found there
> it uses the C preprocessor gcc -E -.
>
Except the script says "$usrinc/\$wanted" which fails for a different reason on my
system: $usrinc is a pathlist, not a single path. However, this doesn't seem to
cause a problem, because the second step works....

>
> Because stdarg.h is not found in the first step it must be found
> in the second step. This second step goes wrong for two reasons:
>
> 1) the shell scripts tests whether the expanded include file
>    name by gcc -E matches */stdarg.h. This test fails because
>    gcc returns a DOS filename with \ e.g.
>    d:\\cygnus\\cygwin-b20  etc, so it does not match.
>
The egcs-1.1.1 returns
"F:/cygnus/cygwin-b20/usr/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.60/include/stdarg.h"
so the match succeeds. However, the correction to the search regex will work in
both cases.

>
>    There are two solutions:
>    - change the matching condition in findhdr from
>      */stdarg.h  to  *[/\\]stdarg.h
>    - make gcc -E - return a unixy file name
>
> 2) Even with this test fixed it still goes wrong.
>    This seems to be a bug in the configure script.
>    The configure scripts sets variable name in a while
>    loop that is the end of a pipe. Because the while is
>    in a pipe, it runs in a subshell and variable settings
>    are local to that subshell.
>
????. I understand the theory, but my build seemed to work okay. However, I don't
see how including Mr. Burgers' fixes will hurt anything, so I'll go ahead an add
them to the "patch", unless anyone can think of a good reason not to.

> *) Furthermore, I'd just add that I had some problems while building perl
> if source files were extracted in a binary mounted partition. BUT I also
> read some testimony regarding the contrary (i.e. you need to mount it as
> binary) ! Therefore, It's just a hint, but if you experience some problems
> (sadly, I forgot to save the error messages), try different mount mode.

I extracted into a binary mounted partition. My *guess* is that you might have
used WinZip or somesuch to extract the source. If WinZip converted all newlines to
\013\010, AND the partition was mounted binary, then that would cause problems.

> *) make test
>
> Here is the result after applying your modifications :
>
> > make test
> Failed 7 test scripts out of 186, 91.40% okay.

> >cd t
> >perl harness
>
> Failed Test  Status Wstat Total Fail  Failed  List of failed
> -------------------------------------------------------------------------------
> io/fs.t                      26    4  15.38%  5, 7, 9-10
> lib/anydbm.t      2   512    12    9  75.00%  2, 5-12
> lib/findbin.t                 1    1 100.00%  1
> lib/sdbm.t        2   512    18   15  83.33%  2, 5-18
> op/magic.t                   35    1   2.86%  23
> op/stat.t                    58    6  10.34%  2, 9, 19-20, 26, 35
> op/taint.t                  149    3   2.01%  1, 3, 31
> 9 tests skipped, plus 20 subtests skipped.
> Failed 7/186 test scripts, 96.24% okay. 39/6193 subtests failed, 99.37% okay.
>
> (anydbm and sdbm might be different if you mounted your partition as binary).

Yup, they are different. Here's my output, *without* your changes to the testing
scripts.

>make test
Failed 4 test scripts out of 186, 92.47% okay.
>cd t
>perl harness

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/findbin.t                 1    1 100.00%  1
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    2   3.45%  4, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 20 subtests skipped.
Failed 4/186 test scripts, 97.85% okay. 7/6191 subtests failed, 99.89% okay.

(skipped tests: lib/thread, lib/posix, lib/odbm, lib/ndbm, lib/ipc_sysv, lib/gdbm,
lib/db-recno, lib/db-hash, lib/db-btree, op/groups)

Now, all three of your patches address problems I didn't see; the main difference
between us being binary vs. text mounts. If that is the case, should these tests
be skipped for all cygwin (binary and text mount) or should the tests be fixed so
that they work for both binary and text mounts? I'm not sure if the second option
means hacking the test scripts, or hacking perl itself.

> Some of them just fail because they should NOT be executed in a win32
> implementation. They should be skipped. Sadly, the test behind this does
> NOT handle cygwin32 environment, just plain MS32 by comparing OS name to
> MSWin32 ($^O eq 'MSWin32'). Let's add a test for cygwin ($^O =~ /cygwin/).
> Here is a couple of tests I think that might be patched (I could not do
> anything for magic.t, as well as stat.t, which is a known problem) :
>
> <SNIP>
>
> > make test
> Failed 6 test scripts out of 186, 91.40% okay.
>
> > cd t
> > perl harness
>
> Failed Test  Status Wstat Total Fail  Failed  List of failed
> -------------------------------------------------------------------------------
> lib/anydbm.t      2   512    12    8  66.67%  5-12
> lib/findbin.t                 1    1 100.00%  1
> lib/sdbm.t        2   512    18   14  77.78%  5-18
> op/magic.t                   35    1   2.86%  23
> op/stat.t                    58    6  10.34%  2, 9, 19-20, 26, 35
> op/taint.t                  149    3   2.01%  1, 3, 31
> 10 tests skipped, plus 22 subtests skipped.
> Failed 6/186 test scripts, 96.77% okay. 33/6167 subtests failed, 99.46% okay.
>
> Which is slightly better :)

--Chuck


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 13:27 06/03/99 -0500, Charles Wilson wrote:

>BTW, did you apply the patch to a
>pristine copy of the source, or had you already applied the changes from Teun
>Burgers (below)?

No, from the pristine copy of course :) My perl is working quite right I
guess, I just wanted to help you controlling your build package, so I
started from the beginning, following your statements.

>Hmmm....here's the relevant part of Teun Burgers' post:

>> The configure script (relevant part in fhdr.old) creates
>> a script findhdr that looks for the header file. findhr first
>> simply tests for existance (test -f) of the .h file in
>> H-i586-cygwin32/i586-cygwin32/include and if not found there
>> it uses the C preprocessor gcc -E -.

>Except the script says "$usrinc/\$wanted" which fails for a different reason 
>on my system: $usrinc is a pathlist, not a single path. However, this
doesn't seem to
>cause a problem, because the second step works....

[...]

>The egcs-1.1.1 returns
>"F:/cygnus/cygwin-b20/usr/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.60/incl
>ude/stdarg.h" so the match succeeds. 

Oh yes, *NOW* I remember, I had the same problem, but read an article in
the list stated the egcs 1.1.1 fixed a similar problem. I upgraded to egcs
1.1.1 and that solved my problem. Therefore, I guess that this information
*definitely* need a place in your build instructions : egcs 1.1.1 might be
handy.

>However, the correction to the search regex will work in
>both cases.

[..]

>????. I understand the theory, but my build seemed to work okay.

egcs 1.1.1 :)

>However, I 
>don't see how including Mr. Burgers' fixes will hurt anything, so I'll go
ahead an 
>add them to the "patch", unless anyone can think of a good reason not to.

I tried, but was unable to find the relevant part to patch.

>> *) Furthermore, I'd just add that I had some problems while building perl
>> if source files were extracted in a binary mounted partition. BUT I also
>> read some testimony regarding the contrary (i.e. you need to mount it as
>> binary) ! Therefore, It's just a hint, but if you experience some problems
>> (sadly, I forgot to save the error messages), try different mount mode.

>I extracted into a binary mounted partition. My *guess* is that you might have
>used WinZip or somesuch to extract the source. If WinZip converted all 
>newlines to \013\010, AND the partition was mounted binary, then that
would cause problems.

Nope, I'm aware of the Winzip problem, and I'm taking care of that, by
systematically using tar / gzip :)

>> *) make test

(continuing in your answer to Earnie)

______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Sebastien Barre wrote:

> At 13:27 06/03/99 -0500, Charles Wilson wrote:
>
> >BTW, did you apply the patch to a
> >pristine copy of the source, or had you already applied the changes from Teun
> >Burgers (below)?
>
> No, from the pristine copy of course :) My perl is working quite right I
> guess, I just wanted to help you controlling your build package, so I
> started from the beginning, following your statements.

I was fairly sure that was the case, but it's best to eliminate the simple things
first.

> <snip>

> Therefore, I guess that this information

> *definitely* need a place in your build instructions : egcs 1.1.1 might be
> handy.
>

Okay. I'll update the build-kit soon.

> <snip>

> >However, I

> >don't see how including Mr. Burgers' fixes will hurt anything, so I'll go
> ahead an
> >add them to the "patch", unless anyone can think of a good reason not to.
>
> I tried, but was unable to find the relevant part to patch.
>

I found the relevant part, and have changed the build-kit to include this patch.
Even though it probably doesn't matter if you're using egcs-1.1.1.

>
> >> *) Furthermore, I'd just add that I had some problems while building perl
> >> if source files were extracted in a binary mounted partition. BUT I also
> >> read some testimony regarding the contrary (i.e. you need to mount it as
> >> binary) ! Therefore, It's just a hint, but if you experience some problems
> >> (sadly, I forgot to save the error messages), try different mount mode.
>
> >I extracted into a binary mounted partition. My *guess* is that you might have
> >used WinZip or somesuch to extract the source. If WinZip converted all
> >newlines to \013\010, AND the partition was mounted binary, then that
> would cause problems.
>
> Nope, I'm aware of the Winzip problem, and I'm taking care of that, by
> systematically using tar / gzip :)

Well, then I'm stumped. I don't know what the *build* problem is (or even if there
is one, after applying all these patches) under text / binary mounts. *make test*
problems are a whole different kettle of fish....continued in next message.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Sebastien Barre wrote:

> At 13:27 06/03/99 -0500, Charles Wilson wrote:
>
> >BTW, did you apply the patch to a
> >pristine copy of the source, or had you already applied the changes from Teun
> >Burgers (below)?
>
> No, from the pristine copy of course :) My perl is working quite right I
> guess, I just wanted to help you controlling your build package, so I
> started from the beginning, following your statements.

I was fairly sure that was the case, but it's best to eliminate the simple things
first.

> <snip>

> Therefore, I guess that this information

> *definitely* need a place in your build instructions : egcs 1.1.1 might be
> handy.
>

Okay. I'll update the build-kit soon.

> <snip>

> >However, I

> >don't see how including Mr. Burgers' fixes will hurt anything, so I'll go
> ahead an
> >add them to the "patch", unless anyone can think of a good reason not to.
>
> I tried, but was unable to find the relevant part to patch.
>

I found the relevant part, and have changed the build-kit to include this patch.
Even though it probably doesn't matter if you're using egcs-1.1.1.

>
> >> *) Furthermore, I'd just add that I had some problems while building perl
> >> if source files were extracted in a binary mounted partition. BUT I also
> >> read some testimony regarding the contrary (i.e. you need to mount it as
> >> binary) ! Therefore, It's just a hint, but if you experience some problems
> >> (sadly, I forgot to save the error messages), try different mount mode.
>
> >I extracted into a binary mounted partition. My *guess* is that you might have
> >used WinZip or somesuch to extract the source. If WinZip converted all
> >newlines to \013\010, AND the partition was mounted binary, then that
> would cause problems.
>
> Nope, I'm aware of the Winzip problem, and I'm taking care of that, by
> systematically using tar / gzip :)

Well, then I'm stumped. I don't know what the *build* problem is (or even if there
is one, after applying all these patches) under text / binary mounts. *make test*
problems are a whole different kettle of fish....continued in next message.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 13:27 06/03/99 -0500, Charles Wilson wrote:

>BTW, did you apply the patch to a
>pristine copy of the source, or had you already applied the changes from Teun
>Burgers (below)?

No, from the pristine copy of course :) My perl is working quite right I
guess, I just wanted to help you controlling your build package, so I
started from the beginning, following your statements.

>Hmmm....here's the relevant part of Teun Burgers' post:

>> The configure script (relevant part in fhdr.old) creates
>> a script findhdr that looks for the header file. findhr first
>> simply tests for existance (test -f) of the .h file in
>> H-i586-cygwin32/i586-cygwin32/include and if not found there
>> it uses the C preprocessor gcc -E -.

>Except the script says "$usrinc/\$wanted" which fails for a different reason 
>on my system: $usrinc is a pathlist, not a single path. However, this
doesn't seem to
>cause a problem, because the second step works....

[...]

>The egcs-1.1.1 returns
>"F:/cygnus/cygwin-b20/usr/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.60/incl
>ude/stdarg.h" so the match succeeds. 

Oh yes, *NOW* I remember, I had the same problem, but read an article in
the list stated the egcs 1.1.1 fixed a similar problem. I upgraded to egcs
1.1.1 and that solved my problem. Therefore, I guess that this information
*definitely* need a place in your build instructions : egcs 1.1.1 might be
handy.

>However, the correction to the search regex will work in
>both cases.

[..]

>????. I understand the theory, but my build seemed to work okay.

egcs 1.1.1 :)

>However, I 
>don't see how including Mr. Burgers' fixes will hurt anything, so I'll go
ahead an 
>add them to the "patch", unless anyone can think of a good reason not to.

I tried, but was unable to find the relevant part to patch.

>> *) Furthermore, I'd just add that I had some problems while building perl
>> if source files were extracted in a binary mounted partition. BUT I also
>> read some testimony regarding the contrary (i.e. you need to mount it as
>> binary) ! Therefore, It's just a hint, but if you experience some problems
>> (sadly, I forgot to save the error messages), try different mount mode.

>I extracted into a binary mounted partition. My *guess* is that you might have
>used WinZip or somesuch to extract the source. If WinZip converted all 
>newlines to \013\010, AND the partition was mounted binary, then that
would cause problems.

Nope, I'm aware of the Winzip problem, and I'm taking care of that, by
systematically using tar / gzip :)

>> *) make test

(continuing in your answer to Earnie)

______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

Sebastien Barre wrote:

> Very good, thanks !. I tested it, and it works. After applying the patch,
> one might have to change his paths in hints/cygwin32.sh, otherwise it's
> perfect.

Yeah, that's true. The "build-instructions" were more in the nature of "here's how
I built the binary kit" than a general guide. BTW, did you apply the patch to a
pristine copy of the source, or had you already applied the changes from Teun
Burgers (below)?

> >Please comment on both the collected build instructions and the binary
> >distribution.
>
> *) Steven Morlock  published TWO articles (a correction to the first one),
> but you did not include the second one (which is related to binary mode).
>
> Re: HOWTO: Builiding Perl under Win95/98 using Cygwin32
> Author: Steven Morlock <newspost@morlock.net>
> Date: 1998/12/22
> Forum: comp.lang.perl.misc
>
> It's not that important because you included the modification in your patch :
>
> + #if defined(__CYGWIN32__)
> +   /* USEMYBINMODE
> ...

Oops. I'll go grab that usenet posting and stick it in the build instruction kit.

> *) I also forgot to mention this article :
>
>      To: cygwin@sourceware.cygnus.com
>      Subject: configure and cpp problem (Was: bug: missing include files in
> B20.1)
>      From: Teun Burgers <burgers@ecn.nl>
>      Date: Mon, 22 Feb 1999 16:52:09 +0100
>
> But I seems to me the one DO NOT need it (but I kept it, just in case). You
> might have a look anyway.

Hmmm....here's the relevant part of Teun Burgers' post:

> The configure script (relevant part in fhdr.old) creates
> a script findhdr that looks for the header file. findhr first
> simply tests for existance (test -f) of the .h file in
> H-i586-cygwin32/i586-cygwin32/include and if not found there
> it uses the C preprocessor gcc -E -.
>
Except the script says "$usrinc/\$wanted" which fails for a different reason on my
system: $usrinc is a pathlist, not a single path. However, this doesn't seem to
cause a problem, because the second step works....

>
> Because stdarg.h is not found in the first step it must be found
> in the second step. This second step goes wrong for two reasons:
>
> 1) the shell scripts tests whether the expanded include file
>    name by gcc -E matches */stdarg.h. This test fails because
>    gcc returns a DOS filename with \ e.g.
>    d:\\cygnus\\cygwin-b20  etc, so it does not match.
>
The egcs-1.1.1 returns
"F:/cygnus/cygwin-b20/usr/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.60/include/stdarg.h"
so the match succeeds. However, the correction to the search regex will work in
both cases.

>
>    There are two solutions:
>    - change the matching condition in findhdr from
>      */stdarg.h  to  *[/\\]stdarg.h
>    - make gcc -E - return a unixy file name
>
> 2) Even with this test fixed it still goes wrong.
>    This seems to be a bug in the configure script.
>    The configure scripts sets variable name in a while
>    loop that is the end of a pipe. Because the while is
>    in a pipe, it runs in a subshell and variable settings
>    are local to that subshell.
>
????. I understand the theory, but my build seemed to work okay. However, I don't
see how including Mr. Burgers' fixes will hurt anything, so I'll go ahead an add
them to the "patch", unless anyone can think of a good reason not to.

> *) Furthermore, I'd just add that I had some problems while building perl
> if source files were extracted in a binary mounted partition. BUT I also
> read some testimony regarding the contrary (i.e. you need to mount it as
> binary) ! Therefore, It's just a hint, but if you experience some problems
> (sadly, I forgot to save the error messages), try different mount mode.

I extracted into a binary mounted partition. My *guess* is that you might have
used WinZip or somesuch to extract the source. If WinZip converted all newlines to
\013\010, AND the partition was mounted binary, then that would cause problems.

> *) make test
>
> Here is the result after applying your modifications :
>
> > make test
> Failed 7 test scripts out of 186, 91.40% okay.

> >cd t
> >perl harness
>
> Failed Test  Status Wstat Total Fail  Failed  List of failed
> -------------------------------------------------------------------------------
> io/fs.t                      26    4  15.38%  5, 7, 9-10
> lib/anydbm.t      2   512    12    9  75.00%  2, 5-12
> lib/findbin.t                 1    1 100.00%  1
> lib/sdbm.t        2   512    18   15  83.33%  2, 5-18
> op/magic.t                   35    1   2.86%  23
> op/stat.t                    58    6  10.34%  2, 9, 19-20, 26, 35
> op/taint.t                  149    3   2.01%  1, 3, 31
> 9 tests skipped, plus 20 subtests skipped.
> Failed 7/186 test scripts, 96.24% okay. 39/6193 subtests failed, 99.37% okay.
>
> (anydbm and sdbm might be different if you mounted your partition as binary).

Yup, they are different. Here's my output, *without* your changes to the testing
scripts.

>make test
Failed 4 test scripts out of 186, 92.47% okay.
>cd t
>perl harness

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/findbin.t                 1    1 100.00%  1
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    2   3.45%  4, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 20 subtests skipped.
Failed 4/186 test scripts, 97.85% okay. 7/6191 subtests failed, 99.89% okay.

(skipped tests: lib/thread, lib/posix, lib/odbm, lib/ndbm, lib/ipc_sysv, lib/gdbm,
lib/db-recno, lib/db-hash, lib/db-btree, op/groups)

Now, all three of your patches address problems I didn't see; the main difference
between us being binary vs. text mounts. If that is the case, should these tests
be skipped for all cygwin (binary and text mount) or should the tests be fixed so
that they work for both binary and text mounts? I'm not sure if the second option
means hacking the test scripts, or hacking perl itself.

> Some of them just fail because they should NOT be executed in a win32
> implementation. They should be skipped. Sadly, the test behind this does
> NOT handle cygwin32 environment, just plain MS32 by comparing OS name to
> MSWin32 ($^O eq 'MSWin32'). Let's add a test for cygwin ($^O =~ /cygwin/).
> Here is a couple of tests I think that might be patched (I could not do
> anything for magic.t, as well as stat.t, which is a known problem) :
>
> <SNIP>
>
> > make test
> Failed 6 test scripts out of 186, 91.40% okay.
>
> > cd t
> > perl harness
>
> Failed Test  Status Wstat Total Fail  Failed  List of failed
> -------------------------------------------------------------------------------
> lib/anydbm.t      2   512    12    8  66.67%  5-12
> lib/findbin.t                 1    1 100.00%  1
> lib/sdbm.t        2   512    18   14  77.78%  5-18
> op/magic.t                   35    1   2.86%  23
> op/stat.t                    58    6  10.34%  2, 9, 19-20, 26, 35
> op/taint.t                  149    3   2.01%  1, 3, 31
> 10 tests skipped, plus 22 subtests skipped.
> Failed 6/186 test scripts, 96.77% okay. 33/6167 subtests failed, 99.46% okay.
>
> Which is slightly better :)

--Chuck


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 16:13 05/03/99 -0500, Charles Wilson wrote:

>I've taken Sebastien Barre's suggestions and Steven Morlock's instructions and
>successfully compiled perl5.005_02 under Cygwin B20.1 and WinNT4sp4. I took
>all their suggestions and created a patch file and collected the instructions
>together in the attached package (6kB).

Very good, thanks !. I tested it, and it works. After applying the patch,
one might have to change his paths in hints/cygwin32.sh, otherwise it's
perfect.

>Please comment on both the collected build instructions and the binary
>distribution.

*) Steven Morlock  published TWO articles (a correction to the first one),
but you did not include the second one (which is related to binary mode). 

Re: HOWTO: Builiding Perl under Win95/98 using Cygwin32  
Author: Steven Morlock <newspost@morlock.net>
Date: 1998/12/22
Forum: comp.lang.perl.misc 

It's not that important because you included the modification in your patch :

+ #if defined(__CYGWIN32__)
+   /* USEMYBINMODE
...

*) I also forgot to mention this article :

     To: cygwin@sourceware.cygnus.com 
     Subject: configure and cpp problem (Was: bug: missing include files in
B20.1) 
     From: Teun Burgers <burgers@ecn.nl> 
     Date: Mon, 22 Feb 1999 16:52:09 +0100 

But I seems to me the one DO NOT need it (but I kept it, just in case). You
might have a look anyway.

*) Furthermore, I'd just add that I had some problems while building perl
if source files were extracted in a binary mounted partition. BUT I also
read some testimony regarding the contrary (i.e. you need to mount it as
binary) ! Therefore, It's just a hint, but if you experience some problems
(sadly, I forgot to save the error messages), try different mount mode.

*) make test

Here is the result after applying your modifications :

> make test
Failed 7 test scripts out of 186, 91.40% okay.

>cd t
>perl harness

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
io/fs.t                      26    4  15.38%  5, 7, 9-10
lib/anydbm.t      2   512    12    9  75.00%  2, 5-12
lib/findbin.t                 1    1 100.00%  1
lib/sdbm.t        2   512    18   15  83.33%  2, 5-18
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  2, 9, 19-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
9 tests skipped, plus 20 subtests skipped.
Failed 7/186 test scripts, 96.24% okay. 39/6193 subtests failed, 99.37% okay.

(anydbm and sdbm might be different if you mounted your partition as binary).

Some of them just fail because they should NOT be executed in a win32
implementation. They should be skipped. Sadly, the test behind this does
NOT handle cygwin32 environment, just plain MS32 by comparing OS name to
MSWin32 ($^O eq 'MSWin32'). Let's add a test for cygwin ($^O =~ /cygwin/).
Here is a couple of tests I think that might be patched (I could not do
anything for magic.t, as well as stat.t, which is a known problem) :

diff -urN perl5.005_02/t/io/fs.t.orig perl5.005_02/t/io/fs.t
--- perl5.005_02/t/io/fs.t.orig	Sat Mar 06 12:18:26 1999
+++ perl5.005_02/t/io/fs.t	Sat Mar 06 12:18:31 1999
@@ -12,7 +12,7 @@
 $Is_Dosish = ($^O eq 'dos' or $^O eq 'os2');
 
 # avoid win32 (for now)
-do { print "1..0\n"; exit(0); } if $^O eq 'MSWin32';
+do { print "1..0\n"; exit(0); } if $^O eq 'MSWin32' || $^O =~ /cygwin/;
 
 print "1..26\n";
 
diff -urN perl5.005_02/t/lib/anydbm.t.orig perl5.005_02/t/lib/anydbm.t
--- perl5.005_02/t/lib/anydbm.t.orig	Sat Mar 06 12:22:30 1999
+++ perl5.005_02/t/lib/anydbm.t	Sat Mar 06 12:23:04 1999
@@ -22,7 +22,7 @@
 if (! -e $Dfile) {
 	($Dfile) = <Op_dbmx*>;
 }
-if ($^O eq 'amigaos' || $^O eq 'os2' || $^O eq 'MSWin32' || $^O eq 'dos') {
+if ($^O eq 'amigaos' || $^O eq 'os2' || $^O eq 'MSWin32' || $^O eq 'dos'
|| $^O =~ /cygwin/) {
     print "ok 2 # Skipped: different file permission semantics\n";
 }
 else {
diff -urN perl5.005_02/t/lib/sdbm.t.orig perl5.005_02/t/lib/sdbm.t
--- perl5.005_02/t/lib/sdbm.t.orig	Sat Mar 06 12:27:04 1999
+++ perl5.005_02/t/lib/sdbm.t	Sat Mar 06 12:27:10 1999
@@ -27,7 +27,7 @@
 if (! -e $Dfile) {
 	($Dfile) = <Op_dbmx.*>;
 }
-if ($^O eq 'amigaos' || $^O eq 'os2' || $^O eq 'MSWin32' || $^O eq 'dos') {
+if ($^O eq 'amigaos' || $^O eq 'os2' || $^O eq 'MSWin32' || $^O eq 'dos'
|| $^O =~ /cygwin/) {
     print "ok 2 # Skipped: different file permission semantics\n";
 }
 else {


(these patch might be just added to your perl.patch and used with patch -p1).

> make test
Failed 6 test scripts out of 186, 91.40% okay.

> cd t
> perl harness

Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
lib/anydbm.t      2   512    12    8  66.67%  5-12
lib/findbin.t                 1    1 100.00%  1
lib/sdbm.t        2   512    18   14  77.78%  5-18
op/magic.t                   35    1   2.86%  23
op/stat.t                    58    6  10.34%  2, 9, 19-20, 26, 35
op/taint.t                  149    3   2.01%  1, 3, 31
10 tests skipped, plus 22 subtests skipped.
Failed 6/186 test scripts, 96.77% okay. 33/6167 subtests failed, 99.46% okay.

Which is slightly better :)

Hope it helps


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Compiling Perl under b20.1

[Charles Wilson]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

I've taken Sebastien Barre's suggestions and Steven Morlock's instructions and
successfully compiled perl5.005_02 under Cygwin B20.1 and WinNT4sp4. I took
all their suggestions and created a patch file and collected the instructions
together in the attached package (6kB). It can also be downloaded from

ftp://belgarion.resnet.gatech.edu/pub/cygwin/B20/perl-cygwin-instructions.tar.gz

Yoiu can also find a binary distribution of perl at the same location:

ftp://belgarion.resnet.gatech.edu/pub/cygwin/B20/perl5.005_02-cygwinb20.tar.bz2

It's 2.6Meg, unpack from /. It will install into /usr/local/bin/,
/usr/local/man/, /usr/local/lib/, and a few text files into
/usr/local/src/perl5.005_02/. The ftp server has been up & down a lot lately,
please be patient.

Please comment on both the collected build instructions and the binary
distribution.

Thanks,
Chuck Wilson


[-- Attachment #2: perl-cygwin-instructions.tar.gz --]
[-- Type: application/x-gzip, Size: 6208 bytes --]

Re: Compiling Perl under b20.1

[Sebastien Barre]

At 22:04 04/03/99 -0500, Allan Peda wrote:

>Has there been much success with this?  I've done it with MSVC + nmake,
>but I'd get more of a thrill using cygwin.

I did (5.005_002  static build, 91.4% successfull test).

As many people from this list helped me, I'd glad to offer the same. 

Basically, 

*) Read the README.cywin32

*) Edit the hints/cygwin32.sh file to reflect your paths.

Here are also a couple of settings I found useful when performing automatic
build (copy hints/cygwin32.sh to config.sh, and do sh Configure -d)

usedl='n'
i_stdarg='define'
i_varargs='undef'
osname='cygwin_nt-4.0'
osvers='20.1'
archname='cygwin32'
signal_t='int'
d_voidsig='define'
i_sysselct='undef'
signal_t='void'

*) Browse Usenet archives (DejaNews), and find  "HOWTO: Builiding Perl
under Win95/98 using Cygwin32 " 
Steven Morlock <newspost@morlock.net>
1998/12/21
comp.lang.perl.misc

*) Then apply this patch (Thanks to Todd Goodman)

This is my change in Cwd.pm:
--- cwd.pm	Fri Feb 26 21:52:42 1999
+++ cwd.pm.orig	Fri Jan 22 20:49:54 1999
@@ -208,8 +208,6 @@
     my $start = @_ ? shift : '.';
     my($dotdots, $cwd, @pst, @cst, $dir, @tst);
 
-    return cwd() if ( $^O =~ /cygwin/ );
-
     unless (@cst = stat( $start ))
     {

And tell me (email) if it fails.

______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Compiling Perl under b20.1

[Allan Peda]

Has there been much success with this?  I've done it with MSVC + nmake,
but I'd get more of a thrill using cygwin.

I searched at www.qub.com, but it doesn't look too active.  The
directory entry in the distribution with cygwin instructions didn't work
well for me last time I tried.

Allan

A


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com