Re: Compiling Perl under b20.1

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

[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 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

'ntea' CHECK please (was Re: Compiling Perl)

[Sebastien Barre]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

Charles Wilson and I are still fighting with Perl. Some of you pointed me
the fact that adding 'ntea' to CYGWIN could solve some file permissions
problems. True.

Here is a short test (ntea is set). I just want to be sure if these are
KNOWN bugs :


*) First, some stuff about groups and username (as it is might not be
obvious fro you with french names) :

administrateur [541] /tmp$ cat /etc/passwd
Administrateur::500:513:seb::/bin/sh
InvitÚ::501:513:::/bin/sh
Test::1000:513:Yoh::/bin/sh

administrateur [542] /tmp$ cat /etc/group
Aucun::513:
Everyone::0:

=> 'Aucun' means 'None', 'InvitÚ' is 'Guest', 'Administrateur' is... well
you guessed it.


*) Let's create a file

administrateur [544] /tmp$ touch foo
administrateur [545] /tmp$ ll foo
-rw-rw-rw-   1 544      Aucun           0 Mar  8 12:43 foo
administrateur [546] /tmp$ perl -e 'print "yes\n" if -w "foo";'
yes

=> all right, it's writable (perl will display 'yes' if the -w test
succeeds), this is working right because I'm using 'ntea'.
=> that file does NOT belong to me, due to the known NT'ism, it belongs to
the UID of the Administrator group (544).


*) Let's create a directory (which is a kind of file)

administrateur [547] /tmp$ mkdir bar
administrateur [549] /tmp$ ll
total 0
drwxr-xr-x   2 544      Aucun           0 Mar  8 12:44 bar/
-rw-rw-rw-   1 544      Aucun           0 Mar  8 12:43 foo
administrateur [550] /tmp$ perl -e 'print "yes\n" if -w "bar";'

=> *ugh*, 'bar' is NOT writable. Why ? I do not know. Here is a first
problem I'd like to clarify (is it a known bug)
=> that file does NOT belong to me (like foo), due to the known NT'ism, it
belongs to the UID of the Administrator group (544).


*) Let's try to chmod the directory :

administrateur [551] /tmp$ chmod a+w bar
administrateur [552] /tmp$ ll
total 0
drwxr-xr-x   2 544      Aucun           0 Mar  8 12:44 bar/
-rw-rw-rw-   1 544      Aucun           0 Mar  8 12:43 foo

=> No change.


*) Let's change the ownership to my ID (administrateur) :

administrateur [554] /tmp$ chown administrateur bar
administrateur [555] /tmp$ ll
total 0
drwxr-xr-x   2 administ Aucun           0 Mar  8 12:44 bar/
-rw-rw-rw-   1 544      Aucun           0 Mar  8 12:43 foo
administrateur [556] /tmp$ perl -e 'print "yes\n" if -w "bar";'
yes

=> Now it's writable...
=> Do I have to do this for every directory I'll have to create ?

Thanks


______________________________________________________________
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 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

[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 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

'ntea' CHECK please (was Re: Compiling Perl)

[Sebastien Barre]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2607 bytes --]

Charles Wilson and I are still fighting with Perl. Some of you pointed me
the fact that adding 'ntea' to CYGWIN could solve some file permissions
problems. True.

Here is a short test (ntea is set). I just want to be sure if these are
KNOWN bugs :


*) First, some stuff about groups and username (as it is might not be
obvious fro you with french names) :

administrateur [541] /tmp$ cat /etc/passwd
Administrateur::500:513:seb::/bin/sh
InvitÚ::501:513:::/bin/sh
Test::1000:513:Yoh::/bin/sh

administrateur [542] /tmp$ cat /etc/group
Aucun::513:
Everyone::0:

=> 'Aucun' means 'None', 'InvitÚ' is 'Guest', 'Administrateur' is... well
you guessed it.


*) Let's create a file

administrateur [544] /tmp$ touch foo
administrateur [545] /tmp$ ll foo
-rw-rw-rw-   1 544      Aucun           0 Mar  8 12:43 foo
administrateur [546] /tmp$ perl -e 'print "yes\n" if -w "foo";'
yes

=> all right, it's writable (perl will display 'yes' if the -w test
succeeds), this is working right because I'm using 'ntea'.
=> that file does NOT belong to me, due to the known NT'ism, it belongs to
the UID of the Administrator group (544).


*) Let's create a directory (which is a kind of file)

administrateur [547] /tmp$ mkdir bar
administrateur [549] /tmp$ ll
total 0
drwxr-xr-x   2 544      Aucun           0 Mar  8 12:44 bar/
-rw-rw-rw-   1 544      Aucun           0 Mar  8 12:43 foo
administrateur [550] /tmp$ perl -e 'print "yes\n" if -w "bar";'

=> *ugh*, 'bar' is NOT writable. Why ? I do not know. Here is a first
problem I'd like to clarify (is it a known bug)
=> that file does NOT belong to me (like foo), due to the known NT'ism, it
belongs to the UID of the Administrator group (544).


*) Let's try to chmod the directory :

administrateur [551] /tmp$ chmod a+w bar
administrateur [552] /tmp$ ll
total 0
drwxr-xr-x   2 544      Aucun           0 Mar  8 12:44 bar/
-rw-rw-rw-   1 544      Aucun           0 Mar  8 12:43 foo

=> No change.


*) Let's change the ownership to my ID (administrateur) :

administrateur [554] /tmp$ chown administrateur bar
administrateur [555] /tmp$ ll
total 0
drwxr-xr-x   2 administ Aucun           0 Mar  8 12:44 bar/
-rw-rw-rw-   1 544      Aucun           0 Mar  8 12:43 foo
administrateur [556] /tmp$ perl -e 'print "yes\n" if -w "bar";'
yes

=> Now it's writable...
=> Do I have to do this for every directory I'll have to create ?

Thanks


______________________________________________________________
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 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

[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