perl-5.6.1 cygwin problem

perl-5.6.1 cygwin problem

[Reini Urban]

Where to discuss perl-5.6.1 cygwin problems? 
In the perl-porters group or here?

in perl-5.6.1-TRIAL1 gdbm fails for me.
  (Could not tie... on both read and write)
having cygwin-1.1.7, cyggdbm.dll from gdbm-1.8.0-3

Most of the other cpan packages work fine. Installed and tested a lot.

>Since Eric has released a perl package based on the 5.6.1-TRIAL1 code,
>and since his package is slated become an official contribution to the
>cygwin distro, the perl-5.6.0 at CygUtils is obsolete and a dead-end. 
>If you want to upgrade to the newer perl, you should do the following:
-- 
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: perl-5.6.1 cygwin problem

[Eric Fifer]

Reini Urban wrote:
>Where to discuss perl-5.6.1 cygwin problems?
>In the perl-porters group or here?

I subscribe to both lists, so I'm indifferent.
But, if it seems to be Cygwin specific I would
try here first.  If you have the ability to test
on another platform and you get the same results
as Cygwin, then perl5-porters is probably better.

>in perl-5.6.1-TRIAL1 gdbm fails for me.
>  (Could not tie... on both read and write)
>having cygwin-1.1.7, cyggdbm.dll from gdbm-1.8.0-3

Could you provide some details (code would be best)?

>Most of the other cpan packages work fine. Installed and tested a lot.

Great, thanks for testing the package.

Eric Fifer


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 cygwin problem

[Charles Wilson]

Reini Urban wrote:
> 
> Where to discuss perl-5.6.1 cygwin problems?
> In the perl-porters group or here?
> 
> in perl-5.6.1-TRIAL1 gdbm fails for me.
>   (Could not tie... on both read and write)
> having cygwin-1.1.7, cyggdbm.dll from gdbm-1.8.0-3
> 
> Most of the other cpan packages work fine. Installed and tested a lot.
> 
> >Since Eric has released a perl package based on the 5.6.1-TRIAL1 code,
> >and since his package is slated become an official contribution to the
> >cygwin distro, the perl-5.6.0 at CygUtils is obsolete and a dead-end.
> >If you want to upgrade to the newer perl, you should do the following:

Could also be a problem with gdbm itself.  A few questions:

Does this error occur while perl is testing the ndbm emulation routines
within gdbm?
If so, then are you running on a FAT drive?

---> gdbm's ndbm emulation doesn't work on FAT.

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

perl-5.6.1 DB_file support

[Reini Urban]

Reini Urban wrote to <cygwin@sources.redhat.com>
> in perl-5.6.1-TRIAL1 gdbm fails for me.
>   (Could not tie... on both read and write)
> having cygwin-1.1.7, cyggdbm.dll from gdbm-1.8.0-3

Charles Wilson wrote back:
>Does this error occur while perl is testing the ndbm emulation routines
>within gdbm? If so, then are you running on a FAT drive?

it was NTFS (win2k), it failed on textmounts.
on binmode it crashes only randomly. (quite seldom now). 

However, something new:
A minor required db-3.2.3f patch for cygwin

--- db-3.2.3f/os/os_tmpdir.c.orig	Tue Jul  4 21:30:16 2000
+++ db-3.2.3f/os/os_tmpdir.c	Sun Jan  7 21:58:30 2001
@@ -96,6 +96,9 @@
 	}
 #endif
 #ifdef _WIN32
+# ifndef _MAX_PATH
+#  define _MAX_PATH 260
+# endif
 	/* Get the path to the temporary directory. */
 	{int len;
 	 char temp[_MAX_PATH + 1];


And the DB_File patch for perl, tested with db-3.2.3f:
One could also copy the three db headers to /usr/include, but the 
installer leaves them in /usr/local/BerkeleyDB.3.2/include


2001-01-08 02:40:33 rurban
  * support latest BerkeleyDB.3.2 paths

--- perl-5.6.1-1/ext/DB_File/Makefile.PL~	Mon Oct 16 09:12:44 2000
+++ perl-5.6.1-1/ext/DB_File/Makefile.PL	Mon Jan  8 03:38:00 2001
@@ -10,14 +10,13 @@
 
 WriteMakefile(
 	NAME 		=> 'DB_File',
-	LIBS 		=> ["-L/usr/local/lib $LIB"],
+	LIBS 		=> ["-L/usr/local/lib -L/usr/local/BerkeleyDB.3.2/lib $LIB"],
         MAN3PODS        => {},         # Pods will be built by installman.
-	#INC		=> '-I/usr/local/include',
 	VERSION_FROM	=> 'DB_File.pm',
 	OBJECT		=> 'version$(OBJ_EXT) DB_File$(OBJ_EXT)',
 	XSPROTOARG	=> '-noprototypes',
 	DEFINE		=> $OS2 || "",
-	INC => ($^O eq "MacOS" ? "-i ::::db:include" : "")
+	INC => ($^O eq "MacOS" ? "-i ::::db:include" :
"-I/usr/local/BerkeleyDB.3.2/include")
 	);
 
 sub MY::postamble {
--- perl-5.6.1-1/ext/DB_File/hints/cygwin.pl~	Mon Jan  8 03:54:56 2001
+++ perl-5.6.1-1/ext/DB_File/hints/cygwin.pl	Mon Jan  8 03:51:02 2001
@@ -0,0 +1,3 @@
+# latest BerkeleyDB.3.2 from 
+$self->{LIBS} = ['-ldb -L/usr/local/lib -L/usr/local/BerkeleyDB.3.2/lib'];
+$self->{INC} => ["-I/usr/local/BerkeleyDB.3.2/include"];


make test now only fails at the chmod tests:

lib/anydbm...........      0 [main] perl 7624 handle_exceptions: Exception: 
STATUS_ACCESS_VIOLATION
   6593 [main] perl 7624 stackdump: Dumping stack trace to perl.exe.stackdump
FAILED at test 2

a second time:
lib/anydbm...FAILED at test 2
lib/attrs............ok
lib/autoloader.......ok
lib/b................ok
lib/basename.........ok
lib/bigfloat.........ok
lib/bigfltpm.........ok
lib/bigint...........ok
lib/bigintpm.........ok
lib/cgi-form.........ok
lib/cgi-function.....ok
lib/cgi-html.........ok
lib/cgi-pretty.......ok
lib/cgi-request......ok
lib/charnames........ok
lib/checktree........ok
lib/class-struct.....ok
lib/complex..........ok
lib/db-btree.........FAILED at test 20
lib/db-hash..........FAILED at test 16
lib/db-recno.........FAILED at test 18
...
lib/ftmp-tempfile....ok
lib/gdbm.............FAILED at test 2
... and so on

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
  Platform:
    osname=cygwin, osvers=1.1.6(0.3032), archname=cygwin
    uname='cygwin_nt-5.0 fifer 1.1.6(0.3032) 2000-11-21 21:00 i686 unknown '
    config_args='-de'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=und
f
    useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -DHAS_SBRK_PROTO
-fno-strict-ali
sing',
    optimize='-O2',
    cppflags='-DPERL_USE_SAFE_PUTENV -DHAS_SBRK_PROTO -fno-strict-aliasing'
    ccversion='', gccversion='2.95.2-5 19991024 (cygwin experimental)',
gccosan
vers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksiz
=4
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='ld2', ldflags =' -s -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /lib
    libs=-lgdbm -lcrypt
    perllibs=-lcrypt
    libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl5_6_1.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
    cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'


Characteristics of this binary (from libperl):
  Compile-time options: USE_LARGE_FILES
  Locally applied patches:
        v5.6.1-TRIAL1
  Built under cygwin
  Compiled at Jan  8 2001 03:11:19
  @INC:
    /usr/lib/perl5/5.6.1/cygwin
    /usr/lib/perl5/5.6.1
    /usr/lib/perl5/site_perl/5.6.1/cygwin
    /usr/lib/perl5/site_perl/5.6.1
    /usr/lib/perl5/site_perl
    .

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Reini Urban]

NTFS/win2k/cygwin-1.1.7
With CYGWIN=ntea it's completely different. It fails at different tests.
strange:

/usr/src/perl/perl-5.6.1-1/t$ CYGWIN=ntea ./TEST lib/*db*
lib/anydbm.....FAILED at test 3
lib/db-btree...FAILED at test 86
lib/db-hash....FAILED at test 49
lib/db-recno...FAILED at test 49
lib/findbin....ok
lib/gdbm.......      0 [main] perl 3940 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
  20102 [main] perl 3940 stackdump: Dumping stack trace to perl.exe.stackdump
FAILED at test 3
lib/ndbm.......      0 [main] perl 148 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
   8124 [main] perl 148 stackdump: Dumping stack trace to perl.exe.stackdump
FAILED at test 3
lib/odbm.......      0 [main] perl 1964 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
   7534 [main] perl 1964 stackdump: Dumping stack trace to perl.exe.stackdump
FAILED at test 3
lib/sdbm.......ok
Failed 7 test scripts out of 9, 22.22% okay.
   ### Since not all tests were successful, you may want to run some
   ### of them individually and examine any diagnostic messages they
   ### produce.  See the INSTALL document's section on "make test".
   ### If you are testing the compiler, then ignore this message
   ### and run
   ###      ./perl harness
   ### in the directory ./t.
u=0.09  s=0.11  cu=2.86  cs=2.45  scripts=9  tests=663

and a better one:
lib/db-hash....Out of memory during "large" request for 2147487744 bytes,
total
sbrk() is 1064960 bytes at ../lib/DB_File.pm line 258.

This might give me a hint. I'll try again without uselargefiles

Reini Urban wrote:
> lib/anydbm...........      0 [main] perl 7624 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
>    6593 [main] perl 7624 stackdump: Dumping stack trace to perl.exe.stackdump
> FAILED at test 2
> lib/anydbm...FAILED at test 2
> lib/db-btree.........FAILED at test 20
> lib/db-hash..........FAILED at test 16
> lib/db-recno.........FAILED at test 18
> lib/gdbm.............FAILED at test 2

> 
> Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
>   Platform:
>     osname=cygwin, osvers=1.1.6(0.3032), archname=cygwin
>     uname='cygwin_nt-5.0 fifer 1.1.6(0.3032) 2000-11-21 21:00 i686 unknown '
>     config_args='-de'
>     hint=recommended, useposix=true, d_sigaction=define
>     usethreads=undef use5005threads=undef useithreads=undef
> usemultiplicity=undef
>     useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
>     use64bitint=undef use64bitall=undef uselongdouble=undef
>   Compiler:
>     cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -DHAS_SBRK_PROTO
> -fno-strict-alising',
>     optimize='-O2',
>     cppflags='-DPERL_USE_SAFE_PUTENV -DHAS_SBRK_PROTO -fno-strict-aliasing'
>     ccversion='', gccversion='2.95.2-5 19991024 (cygwin experimental)', gccosanvers=''
>     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
>     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
>     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksiz
> =4
>     alignbytes=8, usemymalloc=y, prototype=define
>   Linker and Libraries:
>     ld='ld2', ldflags =' -s -L/usr/local/lib'
>     libpth=/usr/local/lib /usr/lib /lib
>     libs=-lgdbm -lcrypt
>     perllibs=-lcrypt
>     libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl5_6_1.a
>   Dynamic Linking:
>     dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
>     cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'
> 
> Characteristics of this binary (from libperl):
>   Compile-time options: USE_LARGE_FILES
>   Locally applied patches:
>         v5.6.1-TRIAL1
>   Built under cygwin
>   Compiled at Jan  8 2001 03:11:19
>   @INC:
>     /usr/lib/perl5/5.6.1/cygwin
>     /usr/lib/perl5/5.6.1
>     /usr/lib/perl5/site_perl/5.6.1/cygwin
>     /usr/lib/perl5/site_perl/5.6.1
>     /usr/lib/perl5/site_perl
>     .

-- 
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Charles S. Wilson]

Reini Urban wrote:
> However, something new:
> A minor required db-3.2.3f patch for cygwin
> 
> --- db-3.2.3f/os/os_tmpdir.c.orig       Tue Jul  4 21:30:16 2000
> +++ db-3.2.3f/os/os_tmpdir.c    Sun Jan  7 21:58:30 2001
> @@ -96,6 +96,9 @@
>         }
>  #endif
>  #ifdef _WIN32
> +# ifndef _MAX_PATH
> +#  define _MAX_PATH 260
> +# endif
>         /* Get the path to the temporary directory. */
>         {int len;
>          char temp[_MAX_PATH + 1];

AARRGHH.  No no no.  Cygwin is not WIN32.  While some packages, when
ported to cygwin, do rely on code within #ifdef _WIN32 blocks, this is a
mistake.  If you want to use code for WIN32 and for cygwin, then do:

#if defined(_WIN32) || defined(__CYGWIN__)

To accommodate *bad* ports, cygwin's gcc used to define _WIN32, but that
behavior will be dropped soon IIRC.  Also, IMO, burying a constant
definition like that in the middle of a .c is just poor programming. 
Put it in a header file somewhere, at the very least.  Best, find out
where the appropriate cygwin MAXPATH constant is defined in cygwin's
system headers and #include the appropriate .h.
 
> And the DB_File patch for perl, tested with db-3.2.3f:
> One could also copy the three db headers to /usr/include, but the
> installer leaves them in /usr/local/BerkeleyDB.3.2/include
> 
> 2001-01-08 02:40:33 rurban
>   * support latest BerkeleyDB.3.2 paths
> 
> --- perl-5.6.1-1/ext/DB_File/Makefile.PL~       Mon Oct 16 09:12:44 2000
> +++ perl-5.6.1-1/ext/DB_File/Makefile.PL        Mon Jan  8 03:38:00 2001
> @@ -10,14 +10,13 @@
> 
>  WriteMakefile(
>         NAME            => 'DB_File',
> -       LIBS            => ["-L/usr/local/lib $LIB"],
> +       LIBS            => ["-L/usr/local/lib -L/usr/local/BerkeleyDB.3.2/lib $LIB"],

Ugh. I installed my berkdb into /usr/local/berk/.  This should come from
the environment or something, not hardcoded into the Makefile.

--Chuck Wilson

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Earnie Boyd]

"Charles S. Wilson" wrote:
> 
> Reini Urban wrote:
> > However, something new:
> > A minor required db-3.2.3f patch for cygwin
> >
> > --- db-3.2.3f/os/os_tmpdir.c.orig       Tue Jul  4 21:30:16 2000
> > +++ db-3.2.3f/os/os_tmpdir.c    Sun Jan  7 21:58:30 2001
> > @@ -96,6 +96,9 @@
> >         }
> >  #endif
> >  #ifdef _WIN32
> > +# ifndef _MAX_PATH
> > +#  define _MAX_PATH 260
> > +# endif
> >         /* Get the path to the temporary directory. */
> >         {int len;
> >          char temp[_MAX_PATH + 1];
> 
> AARRGHH.  No no no.  Cygwin is not WIN32.  While some packages, when
> ported to cygwin, do rely on code within #ifdef _WIN32 blocks, this is a
> mistake.  If you want to use code for WIN32 and for cygwin, then do:
> 

Well, I'm perplexed that it MAX_PATH and _MAX_PATH isn't set in the
Cygwin headers already somewhere.  I find MAX_PATH in mingw/stdlib.h and
w32api/windef.h.  I find _MAX_PATH defined in mingw/stdlib.h as the
value of MAX_PATH.

> #if defined(_WIN32) || defined(__CYGWIN__)
> 
> To accommodate *bad* ports, cygwin's gcc used to define _WIN32, but that
> behavior will be dropped soon IIRC.

Where did you get that piece of information or are you dreaming? 
Although I would wholeheartedly support such a move, I don't think that
the Cygwin's commercial client list would be that happy about such a
move.

> Also, IMO, burying a constant
> definition like that in the middle of a .c is just poor programming.
> Put it in a header file somewhere, at the very least.  Best, find out
> where the appropriate cygwin MAXPATH constant is defined in cygwin's
> system headers and #include the appropriate .h.
> 

I agree.  But, a caution here is in order, don't include the
mingw/stdlib.h for a Cygwin program, they are only for use by the
-mno-cygwin switch.  IMO, we need to add MAX_PATH and _MAX_PATH to
stdlib.h of Cygwin which requires a Newlib patch.

Cheers,
Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Charles S. Wilson]

Earnie Boyd wrote:
> 
> "Charles S. Wilson" wrote:
> > #if defined(_WIN32) || defined(__CYGWIN__)
> >
> > To accommodate *bad* ports, cygwin's gcc used to define _WIN32, but that
> > behavior will be dropped soon IIRC.
> 
> Where did you get that piece of information or are you dreaming?
> Although I would wholeheartedly support such a move, I don't think that
> the Cygwin's commercial client list would be that happy about such a
> move.

That was my recollection of comments made on the list several months ago
(perhaps even a far as a year?  Maybe even pre-departure-of-Mumit). 
Basically, that "Eventually we want to do X..." kinda thing.  This
'vague recollection' has been reinforced by several recent emails from
you, Earnie, where you recommended using '-mno-win32'.  I assummed that
was because the change I vaguely recalled would soon go into effect.  

Perhaps I misinterpreted, and your advice about '-mno-win32' was in
response to the defeat of the notion to remove '-D_WIN32' from the
cygwin gcc specs.

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Earnie Boyd]

Earnie Boyd wrote:
> 
> "Charles S. Wilson" wrote:
> >
> > Reini Urban wrote:
> > > However, something new:
> > > A minor required db-3.2.3f patch for cygwin
> > >
> > > --- db-3.2.3f/os/os_tmpdir.c.orig       Tue Jul  4 21:30:16 2000
> > > +++ db-3.2.3f/os/os_tmpdir.c    Sun Jan  7 21:58:30 2001
> > > @@ -96,6 +96,9 @@
> > >         }
> > >  #endif
> > >  #ifdef _WIN32
> > > +# ifndef _MAX_PATH
> > > +#  define _MAX_PATH 260
> > > +# endif
> > >         /* Get the path to the temporary directory. */
> > >         {int len;
> > >          char temp[_MAX_PATH + 1];
> >
> > AARRGHH.  No no no.  Cygwin is not WIN32.  While some packages, when
> > ported to cygwin, do rely on code within #ifdef _WIN32 blocks, this is a
> > mistake.  If you want to use code for WIN32 and for cygwin, then do:
> >
> 
> Well, I'm perplexed that it MAX_PATH and _MAX_PATH isn't set in the
> Cygwin headers already somewhere.  I find MAX_PATH in mingw/stdlib.h and
> w32api/windef.h.  I find _MAX_PATH defined in mingw/stdlib.h as the
> value of MAX_PATH.
> 
-8<-
> 
> I agree.  But, a caution here is in order, don't include the
> mingw/stdlib.h for a Cygwin program, they are only for use by the
> -mno-cygwin switch.  IMO, we need to add MAX_PATH and _MAX_PATH to
> stdlib.h of Cygwin which requires a Newlib patch.
> 

I'll correct myself here.  The change needs to be made to limits.h.  In
limits.h we find that we have PATH_MAX defined.  We should also include
MAX_PATH and _MAX_PATH just for the sake of porting idiosyncrasy.

Cheers,
Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Christopher Faylor]

On Mon, Jan 08, 2001 at 08:48:25AM -0500, Earnie Boyd wrote:
>> AARRGHH.  No no no.  Cygwin is not WIN32.  While some packages, when
>> ported to cygwin, do rely on code within #ifdef _WIN32 blocks, this is a
>> mistake.  If you want to use code for WIN32 and for cygwin, then do:
>
>Well, I'm perplexed that it MAX_PATH and _MAX_PATH isn't set in the
>Cygwin headers already somewhere.  I find MAX_PATH in mingw/stdlib.h and
>w32api/windef.h.  I find _MAX_PATH defined in mingw/stdlib.h as the
>value of MAX_PATH.

I don't know for sure but I think that MAX_PATH is a Windows thing.
UNIX programs should probably use PATH_MAX.  PATH_MAX is mentioned
frequently at the Single UNIX Specification site.  MAX_PATH is not
mentioned at all.

>> #if defined(_WIN32) || defined(__CYGWIN__)
>> 
>> To accommodate *bad* ports, cygwin's gcc used to define _WIN32, but that
>> behavior will be dropped soon IIRC.
>
>Where did you get that piece of information or are you dreaming? 
>Although I would wholeheartedly support such a move, I don't think that
>the Cygwin's commercial client list would be that happy about such a
>move.

Actually, since we are now distributing the net release of gcc rather
than some internal Red Hat release, we can make any changes that we
want.  The Red Hat releases can still use whatever makes sense.

I have been reluctant to make the is change because I thought that it
could potentially unleash a torrent of complaints here, actually.

>> Also, IMO, burying a constant
>> definition like that in the middle of a .c is just poor programming.
>> Put it in a header file somewhere, at the very least.  Best, find out
>> where the appropriate cygwin MAXPATH constant is defined in cygwin's
>> system headers and #include the appropriate .h.
>> 
>
>I agree.  But, a caution here is in order, don't include the
>mingw/stdlib.h for a Cygwin program, they are only for use by the
>-mno-cygwin switch.  IMO, we need to add MAX_PATH and _MAX_PATH to
>stdlib.h of Cygwin which requires a Newlib patch.

I don't think that we need this for UNIX ported programs.  It is not
standard.  I can't find it on any of the UNIX systems that I have access
to.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Benjamin Riefenstahl]

Hi Earnie,


Earnie Boyd <earnie_boyd@yahoo.com> writes:
> Well, I'm perplexed that it MAX_PATH and _MAX_PATH isn't set in the
> Cygwin headers already somewhere.

Why should it?

ISO C has FILENAME_MAX in <stdio.h>, which is set to 1024 in my
version of Cygwin.  POSIX has PATH_MAX in <limits.h> which is set to
259 here.  And than there is pathconf() in <unistd.h> for the real
POSIX fans.

MAX_PATH OTOH seems to be an MS Windows invention and is not in any
standard, or is it?


so long, benny
-- 
ISION Internet AG
Benjamin Riefenstahl
mailto:benjamin.riefenstahl@ision.net

Harburger Schlossstr. 1
D-21079 Hamburg
http://www.ision.net


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Earnie Boyd]

"Charles S. Wilson" wrote:
> 
> Earnie Boyd wrote:
> >
> > "Charles S. Wilson" wrote:
> > > #if defined(_WIN32) || defined(__CYGWIN__)
> > >
> > > To accommodate *bad* ports, cygwin's gcc used to define _WIN32, but that
> > > behavior will be dropped soon IIRC.
> >
> > Where did you get that piece of information or are you dreaming?
> > Although I would wholeheartedly support such a move, I don't think that
> > the Cygwin's commercial client list would be that happy about such a
> > move.
> 
> That was my recollection of comments made on the list several months ago
> (perhaps even a far as a year?  Maybe even pre-departure-of-Mumit).
> Basically, that "Eventually we want to do X..." kinda thing.  This
> 'vague recollection' has been reinforced by several recent emails from
> you, Earnie, where you recommended using '-mno-win32'.  I assummed that
> was because the change I vaguely recalled would soon go into effect.
> 
> Perhaps I misinterpreted, and your advice about '-mno-win32' was in
> response to the defeat of the notion to remove '-D_WIN32' from the
> cygwin gcc specs.
> 

As I said, I would support wholeheartedly such a change, however Chris
Faylor and Red Hat would have the final say.  I do think that the WIN32
definitions get in the way of porting UNIX code to Cygwin especially
when Win32 porting is already existing in the code.  I do modify my own
specs file to exclude the WIN32 defines by default and change the
-mno-win32 to -mwin32 however with gcc-2.95.2-6 I had to binary edit
cc1.exe (or was it cpp.exe) to complete this.

Cheers,
Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Christopher Faylor]

On Mon, Jan 08, 2001 at 09:58:27AM -0500, Earnie Boyd wrote:
>As I said, I would support wholeheartedly such a change, however Chris
>Faylor and Red Hat would have the final say.  I do think that the WIN32
>definitions get in the way of porting UNIX code to Cygwin especially
>when Win32 porting is already existing in the code.  I do modify my own
>specs file to exclude the WIN32 defines by default and change the
>-mno-win32 to -mwin32 however with gcc-2.95.2-6 I had to binary edit
>cc1.exe (or was it cpp.exe) to complete this.

If you are saying that gcc is somehow ignoring the specs file, then that
is a bug.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: [BUG] GCC specs ignored [WAS: Re: perl-5.6.1 DB_file support]

[Earnie Boyd]

Christopher Faylor wrote:
> 
> If you are saying that gcc is somehow ignoring the specs file, then that
> is a bug.
> 

Yes, I changed -mno-win32 to -mwin32 and received an error message from
one of the subprocesses, I don't remember now if it was cpp or cc1, that
it was an invalid switch.

Cheers,
Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: [BUG] GCC specs ignored [WAS: Re: perl-5.6.1 DB_file support]

[Christopher Faylor]

On Mon, Jan 08, 2001 at 10:24:09AM -0500, Earnie Boyd wrote:
>Christopher Faylor wrote:
>>If you are saying that gcc is somehow ignoring the specs file, then that
>>is a bug.
>
>Yes, I changed -mno-win32 to -mwin32 and received an error message from
>one of the subprocesses, I don't remember now if it was cpp or cc1, that
>it was an invalid switch.

Ok.  Nevermind.  It makes sense since -mwin32 has never been a valid switch.
You can't create new switches in the specs file, apparently.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Earnie Boyd]

Benjamin Riefenstahl wrote:
> 
> Hi Earnie,
> 
> Earnie Boyd <earnie_boyd@yahoo.com> writes:
> > Well, I'm perplexed that it MAX_PATH and _MAX_PATH isn't set in the
> > Cygwin headers already somewhere.
> 
> Why should it?
> 

For porting idiosyncrasy.


> ISO C has FILENAME_MAX in <stdio.h>, which is set to 1024 in my
> version of Cygwin.  

Well, it appears you've located a different problem.  1024 is too large.

> POSIX has PATH_MAX in <limits.h> which is set to
> 259 here.  And than there is pathconf() in <unistd.h> for the real
> POSIX fans.
> 

Yea, I found that and later corrected myself to say the change should be
to limits.h.  The change could do the POSIX compliance check and not
define them for POSIX only code.

> MAX_PATH OTOH seems to be an MS Windows invention and is not in any
> standard, or is it?
> 

Well, it is a MS Windows standard.  And if _WIN32 is defined shouldn't I
expect to find a Win32 standard definition such as MAX_PATH and
_MAX_PATH defined?  Even Cygwin itself uses MAX_PATH, E.G.:
/usr/include/sys/cygwin.h.

Cheers,
Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Earnie Boyd]

Christopher Faylor wrote:
> 
> >> #if defined(_WIN32) || defined(__CYGWIN__)
> >>
> >> To accommodate *bad* ports, cygwin's gcc used to define _WIN32, but that
> >> behavior will be dropped soon IIRC.
> >
> >Where did you get that piece of information or are you dreaming?
> >Although I would wholeheartedly support such a move, I don't think that
> >the Cygwin's commercial client list would be that happy about such a
> >move.
> 
> Actually, since we are now distributing the net release of gcc rather
> than some internal Red Hat release, we can make any changes that we
> want.  The Red Hat releases can still use whatever makes sense.
> 

This is good news. :)

> I have been reluctant to make the is change because I thought that it
> could potentially unleash a torrent of complaints here, actually.
> 

I think that there is more confusion about which piece of code should be
ported.  If we want Cygwin more UNIX like than Windows like then make
the change and we'll deal with the fallout on the list.  The only
problems will be the GUI stuff that requires X, but perhaps that can be
worked around in the code, especially if there is Win32 support already.

Chuck, Eric or anyone else, have you tried using the -mno-win32 switch
when configuring for perl?  I have successfully built perl without WIN32
definitions successfully for years now.  Although my use of perl is
limited to things like automake and libtool it seams to work fine.  I've
not had to modify anything for Cygwin specifics.

> >> Also, IMO, burying a constant
> >> definition like that in the middle of a .c is just poor programming.
> >> Put it in a header file somewhere, at the very least.  Best, find out
> >> where the appropriate cygwin MAXPATH constant is defined in cygwin's
> >> system headers and #include the appropriate .h.
> >>
> >
> >I agree.  But, a caution here is in order, don't include the
> >mingw/stdlib.h for a Cygwin program, they are only for use by the
> >-mno-cygwin switch.  IMO, we need to add MAX_PATH and _MAX_PATH to
> >stdlib.h of Cygwin which requires a Newlib patch.
> 
> I don't think that we need this for UNIX ported programs.  It is not
> standard.  I can't find it on any of the UNIX systems that I have access
> to.
> 

I agree.  However, IMO, if WIN32 macros are defined then so should
standard MS Windows definitions such ad MAX_PATH and _MAX_PATH.

Cheers,
Earnie.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Christopher Faylor]

On Mon, Jan 08, 2001 at 10:40:21AM -0500, Earnie Boyd wrote:
>Well, it is a MS Windows standard.  And if _WIN32 is defined shouldn't I
>expect to find a Win32 standard definition such as MAX_PATH and
>_MAX_PATH defined?  Even Cygwin itself uses MAX_PATH, E.G.:
>/usr/include/sys/cygwin.h.

Cygwin isn't a UNIX application.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Benjamin Riefenstahl]

> Benjamin Riefenstahl wrote:
> > MAX_PATH OTOH seems to be an MS Windows invention and is not in any
> > standard, or is it?

Earnie Boyd <earnie_boyd@yahoo.com> writes:
> Well, it is a MS Windows standard.

Than it should be in the MS Windows headers (which it is, I suppose. I
haven't MingW installed currently to check).  No problem with that.
Microsoft's Platform SDK has MAX_PATH in <windef.h> which seems
sensible.

> And if _WIN32 is defined shouldn't I expect to find a Win32 standard
> definition such as MAX_PATH and _MAX_PATH defined?  Even Cygwin
> itself uses MAX_PATH, E.G.: /usr/include/sys/cygwin.h.

The code in question is covered by an "#ifdef WINVER" so it's only
included for programs that have included <windows.h> or <windef.h>
before <cygwin.h>.
-- 
ISION Internet AG
Benjamin Riefenstahl
mailto:benjamin.riefenstahl@ision.net

Harburger Schlossstr. 1
D-21079 Hamburg
http://www.ision.net


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Earnie Boyd]

Christopher Faylor wrote:
> 
> On Mon, Jan 08, 2001 at 10:40:21AM -0500, Earnie Boyd wrote:
> >Well, it is a MS Windows standard.  And if _WIN32 is defined shouldn't I
> >expect to find a Win32 standard definition such as MAX_PATH and
> >_MAX_PATH defined?  Even Cygwin itself uses MAX_PATH, E.G.:
> >/usr/include/sys/cygwin.h.
> 
> Cygwin isn't a UNIX application.
> 

Uh, I don't consider Cygwin an application, it is a runtime library used
to make applications run.  My statement that if _WIN32 is defined, then
I should expect that standard Win32 definitions also be defined still
stands.  MAX_PATH is just an example of one of those definitions.

Cheers,
Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Christopher Faylor]

On Mon, Jan 08, 2001 at 12:25:20PM -0500, Earnie Boyd wrote:
>Christopher Faylor wrote:
>> 
>> On Mon, Jan 08, 2001 at 10:40:21AM -0500, Earnie Boyd wrote:
>> >Well, it is a MS Windows standard.  And if _WIN32 is defined shouldn't I
>> >expect to find a Win32 standard definition such as MAX_PATH and
>> >_MAX_PATH defined?  Even Cygwin itself uses MAX_PATH, E.G.:
>> >/usr/include/sys/cygwin.h.
>> 
>> Cygwin isn't a UNIX application.
>
>Uh, I don't consider Cygwin an application, it is a runtime library used
>to make applications run.

Ok.  Let me rephrase then: "Cygwin isn't a UNIX runtime library used to
make applications run."

>My statement that if _WIN32 is defined, then I should expect that
>standard Win32 definitions also be defined still stands.  MAX_PATH is
>just an example of one of those definitions.

MAX_PATH *is* defined.  It is in /cygnus/i686-pc-cygwin/include/w32api/windef.h.

The code in /usr/include/sys/cygwin.h is only used when WINVER is
defined.  WINVER is also defined in windef.h, although the real intent
is that the sys/cygwin.h include file should be preceded by an '#include
<windows.h>' if you are attempting to use any of the stuff controlled by
the '#ifdef WINVER' conditional.  Besides "MAX_PATH", there are also
other Windows-specific constructs inside this conditional block like
"HANDLE", and "DWORD".

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Earnie Boyd]

Benjamin Riefenstahl wrote:
> 
> > Benjamin Riefenstahl wrote:
> > > MAX_PATH OTOH seems to be an MS Windows invention and is not in any
> > > standard, or is it?
> 
> Earnie Boyd <earnie_boyd@yahoo.com> writes:
> > Well, it is a MS Windows standard.
> 
> Than it should be in the MS Windows headers (which it is, I suppose. I
> haven't MingW installed currently to check).  No problem with that.
> Microsoft's Platform SDK has MAX_PATH in <windef.h> which seems
> sensible.
> 

Yes indeed they are.

> > And if _WIN32 is defined shouldn't I expect to find a Win32 standard
> > definition such as MAX_PATH and _MAX_PATH defined?  Even Cygwin
> > itself uses MAX_PATH, E.G.: /usr/include/sys/cygwin.h.
> 
> The code in question is covered by an "#ifdef WINVER" so it's only
> included for programs that have included <windows.h> or <windef.h>
> before <cygwin.h>.

So, it appears the correct fix is to modify the code to
s/_MAX_PATH/MAX_PATH/.  Or perhaps

  #ifdef MAX_PATH
  # ifndef _MAX_PATH
  #  define _MAX_PATH MAX_PATH
  # endif
  #endif

Cheers,
Earnie.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: perl-5.6.1 DB_file support

[Paul Marquess]

From: Reini Urban [ mailto:rurban@sbox.tu-graz.ac.at ]

thanks for the feedback.

...
>
> And the DB_File patch for perl, tested with db-3.2.3f:
> One could also copy the three db headers to /usr/include, but the
> installer leaves them in /usr/local/BerkeleyDB.3.2/include
>
>
> 2001-01-08 02:40:33 rurban
>   * support latest BerkeleyDB.3.2 paths
>
> --- perl-5.6.1-1/ext/DB_File/Makefile.PL~	Mon Oct 16 09:12:44 2000
> +++ perl-5.6.1-1/ext/DB_File/Makefile.PL	Mon Jan  8 03:38:00 2001
> @@ -10,14 +10,13 @@
>
>  WriteMakefile(
>  	NAME 		=> 'DB_File',
> -	LIBS 		=> ["-L/usr/local/lib $LIB"],
> +	LIBS 		=> ["-L/usr/local/lib
> -L/usr/local/BerkeleyDB.3.2/lib $LIB"],
>          MAN3PODS        => {},         # Pods will be built by
> installman.
> -	#INC		=> '-I/usr/local/include',
>  	VERSION_FROM	=> 'DB_File.pm',
>  	OBJECT		=> 'version$(OBJ_EXT) DB_File$(OBJ_EXT)',
>  	XSPROTOARG	=> '-noprototypes',
>  	DEFINE		=> $OS2 || "",
> -	INC => ($^O eq "MacOS" ? "-i ::::db:include" : "")
> +	INC => ($^O eq "MacOS" ? "-i ::::db:include" :
> "-I/usr/local/BerkeleyDB.3.2/include")
>  	);
>
>  sub MY::postamble {
> --- perl-5.6.1-1/ext/DB_File/hints/cygwin.pl~	Mon Jan  8 03:54:56 2001
> +++ perl-5.6.1-1/ext/DB_File/hints/cygwin.pl	Mon Jan  8 03:51:02 2001
> @@ -0,0 +1,3 @@
> +# latest BerkeleyDB.3.2 from
> +$self->{LIBS} = ['-ldb -L/usr/local/lib
> -L/usr/local/BerkeleyDB.3.2/lib'];

Should that not be

 $self->{LIBS} = ['-L/usr/local/lib -L/usr/local/BerkeleyDB.3.2/lib -ldb']

i.e. the -L before the -l

> +$self->{INC} => ["-I/usr/local/BerkeleyDB.3.2/include"];

Could you try with only the hints/cygwin.pl change? I don't think you should
need the change to Makefile.PL as well.

Hmmm, thinking about this a bit more, I don't think that either
hints/cygwin.pl or Makefile.PL file is the correct place for this change.
The /usr/local/BerkeleyDB.x.y directory prefix is the default location for
installing recent versions of Berkeley DB on all unix-like architectures.
Configure needs to be changed to get it to know about
/usr/local/BerkeleyDB.x.y/lib and /usr/local/BerkeleyDB.x.y/include. Rather
than hard-wiring paths with version numbers (like /usr/local/BerkeleyDB.3.2)
it would be better if Configure could detect what was there itself. If I get
the time, I'll have a look at it.

Regarding the DB_File tests that are failing for you. Berkeley DB 3.2 isn't
officially released yet. The pre-release version I have (which is more
recent than yours) has known problems that make DB_File fail some tests. I
don't intend digging for problems at my end until the Sleepycat folk have a
stable 3.2 for me to play with.

Paul


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Christopher Faylor]

On Mon, Jan 08, 2001 at 12:33:46PM -0500, Christopher Faylor wrote:
>On Mon, Jan 08, 2001 at 12:25:20PM -0500, Earnie Boyd wrote:
>>Christopher Faylor wrote:
>>> 
>>> On Mon, Jan 08, 2001 at 10:40:21AM -0500, Earnie Boyd wrote:
>>> >Well, it is a MS Windows standard.  And if _WIN32 is defined shouldn't I
>>> >expect to find a Win32 standard definition such as MAX_PATH and
>>> >_MAX_PATH defined?  Even Cygwin itself uses MAX_PATH, E.G.:
>>> >/usr/include/sys/cygwin.h.
>>> 
>>> Cygwin isn't a UNIX application.
>>
>>Uh, I don't consider Cygwin an application, it is a runtime library used
>>to make applications run.
>
>Ok.  Let me rephrase then: "Cygwin isn't a UNIX runtime library used to
>make applications run."
>
>>My statement that if _WIN32 is defined, then I should expect that
>>standard Win32 definitions also be defined still stands.  MAX_PATH is
>>just an example of one of those definitions.
>
>MAX_PATH *is* defined.  It is in /cygnus/i686-pc-cygwin/include/w32api/windef.h.
>
>The code in /usr/include/sys/cygwin.h is only used when WINVER is
>defined.  WINVER is also defined in windef.h, although the real intent
>is that the sys/cygwin.h include file should be preceded by an '#include
><windows.h>' if you are attempting to use any of the stuff controlled by
>the '#ifdef WINVER' conditional.  Besides "MAX_PATH", there are also
>other Windows-specific constructs inside this conditional block like
>"HANDLE", and "DWORD".

(Sorry.  Stopped typing too soon.)

So, you can't use cygwin as an example of something that needs to have a
MAX_PATH in stdlib.h.

I do see that there is a definition in the standard Windows version of
stdlib.h from MSVC 6.  This is sort of a gray area, though.

I guess I wouldn't object to something like this being added to stdlib.h
if someone wants to send a patch to newlib@sources.redhat.com:

#ifdef __WIN32__
#ifndef _MAX_DIR
#define _MAX_DIR 256
#endif
#ifndef _MAX_EXT
#define _MAX_EXT 256
#endif
#ifndef _MAX_DRIVE
#define _MAX_DRIVE 3
#endif
#ifndef _MAX_FNAME
#define _MAX_FNAME 256
#endif
#ifndef _MAX_PATH
#define _MAX_PATH 260
#endif
#ifndef MAX_PATH
#define MAX_PATH _MAX_PATH
#endif
etc.
#endif /*__WIN32__*/

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Earnie Boyd]

Christopher Faylor wrote:
> 
> On Mon, Jan 08, 2001 at 12:25:20PM -0500, Earnie Boyd wrote:
> 
> >My statement that if _WIN32 is defined, then I should expect that
> >standard Win32 definitions also be defined still stands.  MAX_PATH is
> >just an example of one of those definitions.
> 
> MAX_PATH *is* defined.  It is in /cygnus/i686-pc-cygwin/include/w32api/windef.h.
> 
> The code in /usr/include/sys/cygwin.h is only used when WINVER is
> defined.  WINVER is also defined in windef.h, although the real intent
> is that the sys/cygwin.h include file should be preceded by an '#include
> <windows.h>' if you are attempting to use any of the stuff controlled by
> the '#ifdef WINVER' conditional.  Besides "MAX_PATH", there are also
> other Windows-specific constructs inside this conditional block like
> "HANDLE", and "DWORD".
> 

Great.  Now let's stop picking on cygwin.h.  ;)

Cheers,
Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: perl-5.6.1 DB_file support

[Charles Wilson]

Earnie Boyd wrote:
> 
> Christopher Faylor wrote:
> >
> > >> #if defined(_WIN32) || defined(__CYGWIN__)
> > >>
> > >> To accommodate *bad* ports, cygwin's gcc used to define _WIN32, but that
> > >> behavior will be dropped soon IIRC.
> > >
> > >Where did you get that piece of information or are you dreaming?
> > >Although I would wholeheartedly support such a move, I don't think that
> > >the Cygwin's commercial client list would be that happy about such a
> > >move.
> >
> > Actually, since we are now distributing the net release of gcc rather
> > than some internal Red Hat release, we can make any changes that we
> > want.  The Red Hat releases can still use whatever makes sense.
> >
> 
> This is good news. :)
> 
> > I have been reluctant to make the is change because I thought that it
> > could potentially unleash a torrent of complaints here, actually.
> >
> 
> I think that there is more confusion about which piece of code should be
> ported.  If we want Cygwin more UNIX like than Windows like then make
> the change and we'll deal with the fallout on the list.  

I, <shudder>, agree -- while terrified of the torrent of FAQs that
<tremble> will soon be generated.

> The only
> problems will be the GUI stuff that requires X, but perhaps that can be
> worked around in the code, especially if there is Win32 support already.
> 
> Chuck, Eric or anyone else, have you tried using the -mno-win32 switch
> when configuring for perl?  

Yes, but not since perl5.005_03 + B20.1 + egcs-2.??.  It worked fine
then.

--Chuck

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

[PATCH 5.7.x] RE: perl-5.6.1 DB_file support

[Paul Marquess]

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

I've a feeling this may not be ok to make use of ls like I do in the patch
enclosed, but it does get perl to check the new default locations for db.h
and libdb.a


Paul


> -----Original Message-----
> From: Paul Marquess [ mailto:Paul_Marquess@Yahoo.co.uk ]
> Sent: 08 January 2001 17:41
> To: Reini Urban; perl5-porters@perl.org; cygwin@sources.redhat.com
> Subject: RE: perl-5.6.1 DB_file support
>
>
> From: Reini Urban [ mailto:rurban@sbox.tu-graz.ac.at ]
>
> thanks for the feedback.
>
> ...
> >
> > And the DB_File patch for perl, tested with db-3.2.3f:
> > One could also copy the three db headers to /usr/include, but the
> > installer leaves them in /usr/local/BerkeleyDB.3.2/include
> >
> >
> > 2001-01-08 02:40:33 rurban
> >   * support latest BerkeleyDB.3.2 paths
> >
> > --- perl-5.6.1-1/ext/DB_File/Makefile.PL~	Mon Oct 16 09:12:44 2000
> > +++ perl-5.6.1-1/ext/DB_File/Makefile.PL	Mon Jan  8 03:38:00 2001
> > @@ -10,14 +10,13 @@
> >
> >  WriteMakefile(
> >  	NAME 		=> 'DB_File',
> > -	LIBS 		=> ["-L/usr/local/lib $LIB"],
> > +	LIBS 		=> ["-L/usr/local/lib
> > -L/usr/local/BerkeleyDB.3.2/lib $LIB"],
> >          MAN3PODS        => {},         # Pods will be built by
> > installman.
> > -	#INC		=> '-I/usr/local/include',
> >  	VERSION_FROM	=> 'DB_File.pm',
> >  	OBJECT		=> 'version$(OBJ_EXT) DB_File$(OBJ_EXT)',
> >  	XSPROTOARG	=> '-noprototypes',
> >  	DEFINE		=> $OS2 || "",
> > -	INC => ($^O eq "MacOS" ? "-i ::::db:include" : "")
> > +	INC => ($^O eq "MacOS" ? "-i ::::db:include" :
> > "-I/usr/local/BerkeleyDB.3.2/include")
> >  	);
> >
> >  sub MY::postamble {
> > --- perl-5.6.1-1/ext/DB_File/hints/cygwin.pl~	Mon Jan  8
> 03:54:56 2001
> > +++ perl-5.6.1-1/ext/DB_File/hints/cygwin.pl	Mon Jan  8
> 03:51:02 2001
> > @@ -0,0 +1,3 @@
> > +# latest BerkeleyDB.3.2 from
> > +$self->{LIBS} = ['-ldb -L/usr/local/lib
> > -L/usr/local/BerkeleyDB.3.2/lib'];
>
> Should that not be
>
>  $self->{LIBS} = ['-L/usr/local/lib -L/usr/local/BerkeleyDB.3.2/lib -ldb']
>
> i.e. the -L before the -l
>
> > +$self->{INC} => ["-I/usr/local/BerkeleyDB.3.2/include"];
>
> Could you try with only the hints/cygwin.pl change? I don't think
> you should
> need the change to Makefile.PL as well.
>
> Hmmm, thinking about this a bit more, I don't think that either
> hints/cygwin.pl or Makefile.PL file is the correct place for this change.
> The /usr/local/BerkeleyDB.x.y directory prefix is the default location for
> installing recent versions of Berkeley DB on all unix-like architectures.
> Configure needs to be changed to get it to know about
> /usr/local/BerkeleyDB.x.y/lib and
> /usr/local/BerkeleyDB.x.y/include. Rather
> than hard-wiring paths with version numbers (like
> /usr/local/BerkeleyDB.3.2)
> it would be better if Configure could detect what was there
> itself. If I get
> the time, I'll have a look at it.
>
> Regarding the DB_File tests that are failing for you. Berkeley DB
> 3.2 isn't
> officially released yet. The pre-release version I have (which is more
> recent than yours) has known problems that make DB_File fail some tests. I
> don't intend digging for problems at my end until the Sleepycat
> folk have a
> stable 3.2 for me to play with.
>
> NOTE: check both /usr/local/BerkeleyDB/[lib|include]
>       and /usr/local/BerkeleyDB.x.y/[lib|include]
>
> Paul
>
>
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
>

[-- Attachment #2: configure.patch --]
[-- Type: text/x-diff, Size: 879 bytes --]

*** Configure.orig	Tue Jan  9 21:35:54 2001
--- Configure	Mon Jan 15 19:52:18 2001
***************
*** 992,997 ****
--- 992,999 ----
  : Set locincpth to "" in a hint file to defeat local include searches.
  locincpth="/usr/local/include /opt/local/include /usr/gnu/include"
  locincpth="$locincpth /opt/gnu/include /usr/GNU/include /opt/GNU/include"
+ tmp_db=`ls -d /usr/local/BerkeleyDB*/include`
+ locincpth="$locincpth $tmp_db"
  :
  : no include file wanted by default
  inclwanted=''
***************
*** 1002,1007 ****
--- 1004,1011 ----
  : Possible local library directories to search.
  loclibpth="/usr/local/lib /opt/local/lib /usr/gnu/lib"
  loclibpth="$loclibpth /opt/gnu/lib /usr/GNU/lib /opt/GNU/lib"
+ tmp_db=`ls -d /usr/local/BerkeleyDB*/lib`
+ loclibpth="$loclibpth $tmp_db"
  
  : general looking path for locating libraries
  glibpth="/lib /usr/lib $xlibpth"

Re: [PATCH 5.7.x] RE: perl-5.6.1 DB_file support

[Jarkko Hietaniemi]

On Mon, Jan 15, 2001 at 08:02:12PM -0000, Paul Marquess wrote:
> I've a feeling this may not be ok to make use of ls like I do in the patch

It's rather naughty but it's inside Configure so it's hard to spot.
You don't need to use ls, though, just echo would do.  But more
importantly, is looking just under /usr/local going to work?
/usr/local may be the default but can't people install BerkeleyDB
pretty anywhere they want?  I have worked in many places where
/usr/local simply wasn't an option, for various technical and/or
political reasons.  I think we need to look under all the preceding
directories (without the /include, with the BerkeleyDB*) in locincpth.

> enclosed, but it does get perl to check the new default locations for db.h
> and libdb.a
> 
> Paul

-- 
$jhi++; # http://www.iki.fi/jhi/
        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: [PATCH 5.7.x] RE: perl-5.6.1 DB_file support

[Paul Marquess]

From: Jarkko Hietaniemi [ mailto:jhi@iki.fi ]

> On Mon, Jan 15, 2001 at 08:02:12PM -0000, Paul Marquess wrote:
> > I've a feeling this may not be ok to make use of ls like I do
> in the patch
>
> It's rather naughty but it's inside Configure so it's hard to spot.
> You don't need to use ls, though, just echo would do.

Quite true.

> But more
> importantly, is looking just under /usr/local going to work?
> /usr/local may be the default but can't people install BerkeleyDB
> pretty anywhere they want?  I have worked in many places where
> /usr/local simply wasn't an option, for various technical and/or
> political reasons.  I think we need to look under all the preceding
> directories (without the /include, with the BerkeleyDB*) in locincpth.

My take on this is that /usr/local/BerkeleyDB*/{include|lib} is the default
place Berkeley DB will install itself if the user doesn't override it, so
it's one of the first places to look for it.

Next is the location where standard Unix/Linux/FreeBSD/etc distributions
store Berkeley DB. Russ Allbery seems to have listed a few in his message.

After that we get into second guessing where a user may have installed it.
Russ' script does a good job of looking in all the likely places. I think we
should adapt it for Configure.

Paul


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple