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