date:20080425

On Apr 25 00:28, Charles Wilson wrote:
 Corinna Vinschen wrote:
 would you mind to build a new tcp-wrappers package exclusively for
 1.7.0, which has IPv6 enabled?

 Fairly soon.

Cool, thanks.  Btw., the openssh package I uploaded to the release-2
area yesterday is already using your csih-based config scripts.

 Also, I *had* planned on installing the cygwin-1.7 tree on my vista 
 machine, but I've had difficulties with bootstrapping and autotooling on 
 Vista+cygwin-1.5: lots of these:

  [main] ? (2152) C:\cygwin\bin\perl.exe: *** fatal error - couldn't 
 allocate heap, Win32 error 487, base 0x99, top 0xC7, reserve_size 
 3010560, allocsize 3014656, page_const 4096

 even after running rebaseall.  And then STFW, and running 'rebaseall -b 
 0x6500' (no joy).

 I guess next I should turn of Address Space Layout Randomization, then 
 re-run rebaseall. Sigh.

I didn't know there's something to switch on or off.  As far as I
understood this issue, the randomization is controlled by a flag in
the executables.  Did I miss something?

 Dare I hope that cygwin-1.7 might be better behaved, or does this have 
 absolutely nothing to do with the cygwin1.dll and is all about the *other* 
 dll's?

There's always hope.  But you can't deny the generic problem with fork
on Windows, unless we are in control of the entire loader process.
Which we aren't.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

Re: [HEADSUP] Let's start a Cygwin 1.7 release area

On Apr 22 18:00, Corinna Vinschen wrote:
 On Apr 22 11:51, Charles Wilson wrote:
  Brian Dessent wrote:
   the DLL already supports
   parallel installs by the fact that it uses /etc/fstab.
  
  Only in very limited cases:
  [...]
  Right?  You still have to worry about the shared memory region name, and
  its format which may vary with DLL version. Plus there still might be
  other stuff that prevents parallel cygwin installs from running
  simultaneously.  And I don't think supporting simultaneous use of
  multiple cygwin installations is one of our goals, is it?
 
 In theory, the latest incarnation of the Cygwin DLL should work 
 in parallel with a 1.5.x DLL.  In theory.  I didn't actually test it.

Now I did.  I installed the 1.7 release first, a few days ago, into
C:\cygwin.  My first step installing 1.5 was to rename C:\cygwin to
C:\somethingelse.  Then I removed the registry keys
HKCU\Software\Cygnus Solutions and HKLM\SOFTWARE\Cygnus Solutions
and installed 1.5 into a directory called C:\cygwin-1.5.  Finally I
renamed C:\somethingelse back to  C:\cygwin.

I'm just running a 1.5 and a 1.7 shell concurrently and both are alive
and healthy.  None of them know from each other, they have separate
process lists, separate /proc dirs, separate everything.

Just this note: Don't mix processes started from the 1.5 and 1.7
installations within the same shell.  Keep 1.5 and 1.7 process trees
separate.  You have been warned.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

Re: tcp-wrappers for 1.7.0


Corinna Vinschen wrote:

On Apr 25 00:28, Charles Wilson wrote:

Corinna Vinschen wrote:

Cool, thanks.  Btw., the openssh package I uploaded to the release-2
area yesterday is already using your csih-based config scripts.


Neat-o.  Keeping fingers crossed...

I guess next I should turn of Address Space Layout Randomization, then 
re-run rebaseall. Sigh.


I didn't know there's something to switch on or off.  As far as I
understood this issue, the randomization is controlled by a flag in
the executables.  Did I miss something?


No, you're right (I think). Since gcc doesn't set that flag, it must not 
be affecting the cygwin fork/exec process.  Besides, ASLR is performed 
only once per bootup; it's not like system DLLs are moving all around in 
every new processes' address space.


Seems like this is just the same old problem...

Dare I hope that cygwin-1.7 might be better behaved, or does this have 
absolutely nothing to do with the cygwin1.dll and is all about the *other* 
dll's?


There's always hope.  But you can't deny the generic problem with fork
on Windows, unless we are in control of the entire loader process.
Which we aren't.


Well, I'm kinda stuck, then. Cygwin (1.5) is virtually useless for 
development on my Vista box, and my WinXP box won't be around forever. 
I'll install 1.7 on both, and hope it works for me on Vista.


Ideas for cygwin-1.9 (not a new one):
(1) add ld.so functionality to cygwin2.dll
(2) ...miracle happens where cygwin .exe's and cygwin .dll's can 
simultaneously have all symbols satisfied, yet not be linked directly to 
DLLs other than cygwin2.dll and windows system .dlls.

(3) cygwin DLL controls loading dependent *cygwin* libraries at runtime.

Step 2 reminds me of the South Park underpants gnomes' business plan.

--
Chuck

Re: tcp-wrappers for 1.7.0

On Apr 25 13:32, Charles Wilson wrote:
 Ideas for cygwin-1.9 (not a new one):
 (1) add ld.so functionality to cygwin2.dll
 (2) ...miracle happens where cygwin .exe's and cygwin .dll's can 
 simultaneously have all symbols satisfied, yet not be linked directly to 
 DLLs other than cygwin2.dll and windows system .dlls.
 (3) cygwin DLL controls loading dependent *cygwin* libraries at runtime.

Wasn't there a guy on the cygwin ML a couple of weeks ago who claimed
to have solved the problem with unresolved symbols?  There was some
shoulder patting on the list, but nothing came out of it so far, right?

 Step 2 reminds me of the South Park underpants gnomes' business plan.

Didn't see this one.  Do you have a pointer to the episode?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

Re: tcp-wrappers for 1.7.0

2008-04-25 Thread Brian Dessent

Corinna Vinschen wrote:

 Wasn't there a guy on the cygwin ML a couple of weeks ago who claimed
 to have solved the problem with unresolved symbols?  There was some
 shoulder patting on the list, but nothing came out of it so far, right?

That would be FlexDLL: http://alain.frisch.fr/flexdll.html which is
essentially a cute trick to implement a dlopen/dlsym interface that
allows for symbols to remain unresolved at link-time and instead be
dynamically resolved by a ld.so-like dynamic linker at runtime.

It's a neat concept, and as far as I can see it works fine.  But the
fact that it is built around explicit dynamic runtime linking (i.e.
dlopen/dlsym) means that it doesn't help in the more general case where
you want the operating system loader to have ELF-like semantics too, not
just for programs that have plugins.

Brian

Re: tcp-wrappers for 1.7.0


Corinna Vinschen wrote:

On Apr 25 13:32, Charles Wilson wrote:

Ideas for cygwin-1.9 (not a new one):
(1) add ld.so functionality to cygwin2.dll
(2) ...miracle happens where cygwin .exe's and cygwin .dll's can 
simultaneously have all symbols satisfied, yet not be linked directly to 
DLLs other than cygwin2.dll and windows system .dlls.

(3) cygwin DLL controls loading dependent *cygwin* libraries at runtime.


Wasn't there a guy on the cygwin ML a couple of weeks ago who claimed
to have solved the problem with unresolved symbols?  There was some
shoulder patting on the list, but nothing came out of it so far, right?


Alain Frisch -- Announce: FlexDLL, flexible DLLs under Windows
http://cygwin.com/ml/cygwin/2007-11/msg00370.html


Step 2 reminds me of the South Park underpants gnomes' business plan.


Didn't see this one.  Do you have a pointer to the episode?


The Plan:
http://en.wikipedia.org/wiki/Image:Gnomes_plan.png

The Episode Gnomes:
http://www.southparkstudios.com/episodes/103595/
(they've shown up in a few other eps, too, but this was the original)

On the original topic...it was a BLODA issue. I thought I had Windows 
Defender turned off in favor of AVG, but for some reason AVG7.5's 
Anti-spyware component got disabled, so WD got turned back on behind my 
back.


I turned it off /again/, upgraded to AVG8.0, and AVG Anti-Spyware (and 
Avti-Virus) were happy again.


Then, I rebased again to 0x6500 (I had earlier tried 0x6300 in 
desperation) and then I was able to bootstrap libtool-git.


--
Chuck

[ITA] octave-3.0.1

Hi all,
as previously discussed I would like to
adopt octave.


octave/setup.hint

sdesc: The GNU Octave language for numerical
computations
category: Math
requires: cygwin lapack gnuplot less libreadline6
libfftw3_3 zlib
ldesc: The GNU Octave language for numerical
computations
Octave is a (mostly Matlab (R) compatible) high-level
language, primarily
intended for numerical computations.  It provides a
convenient command-line
interface for solving linear and nonlinear problems
numerically.

octave-doc/setup.hint
-
sdesc: The GNU Octave. Additional docs in html and
pdf
category: Math
requires: cygwin octave 
ldesc: The GNU Octave language for numerical
computations
Octave is a (mostly Matlab (R) compatible) high-level
language, primarily
intended for numerical computations.  It provides a
convenient command-line
interface for solving linear and nonlinear problems
numerically.

octave-devel/setup.hint
---
sdesc: Header files for the GNU Octave language
category: Math
requires: cygwin octave libncurses-devel libfftw3_3 
external-source: octave
ldesc: Header files for the GNU Octave language.
This packages provides the include files needed to
compile and link
user-supplied code with GNU Octave.  If you only write
interpreted .m
files, you do not need this package.

To download

wget -r
http://matzeri.altervista.org/cygwin/octave/index.html

http://matzeri.altervista.org/cygwin/octave/setup.hint
http://matzeri.altervista.org/cygwin/octave/octave-3.0.1-1-src.tar.bz2
http://matzeri.altervista.org/cygwin/octave/octave-3.0.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/octave/octave-devel/octave-devel-3.0.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/octave/octave-devel/setup.hint
http://matzeri.altervista.org/cygwin/octave/octave-doc/octave-doc-3.0.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/octave/octave-doc/setup.hint
http://matzeri.altervista.org/cygwin/octave/setup.hint


octave-htmldocs, octave-info, octave-info 
are to be considered obsolete

to download 
wget -r
http://matzeri.altervista.org/cygwin/_obsolete/index.html

http://matzeri.altervista.org/cygwin/_obsolete/octave-headers/octave-headers-3.0.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/_obsolete/octave-headers/setup.hint
http://matzeri.altervista.org/cygwin/_obsolete/octave-htmldoc/octave-htmldoc-3.0.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/_obsolete/octave-htmldoc/setup.hint
http://matzeri.altervista.org/cygwin/_obsolete/octave-info/octave-info-3.0.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/_obsolete/octave-info/setup.hint
http://matzeri.altervista.org/cygwin/_obsolete/octave-otags/octave-octave-3.0.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/_obsolete/octave-otags/setup.hint

octave-forge, that is a separate package, 
will be updated as soon as possible.

Regards
Marco



  Tante idee per la salvaguardia del nostro Pianeta su Yahoo! For Good 
http://it.promotions.yahoo.com/forgood/environment.html

Re: tcp-wrappers for 1.7.0

On Apr 25 15:28, Charles Wilson wrote:
 Corinna Vinschen wrote:
 Step 2 reminds me of the South Park underpants gnomes' business plan.
 Didn't see this one.  Do you have a pointer to the episode?

 The Plan:
 http://en.wikipedia.org/wiki/Image:Gnomes_plan.png

 The Episode Gnomes:
 http://www.southparkstudios.com/episodes/103595/
 (they've shown up in a few other eps, too, but this was the original)

LOL!  Cygwin's development is definitely in phase two.

 On the original topic...it was a BLODA issue. I thought I had Windows 
 Defender turned off in favor of AVG, but for some reason AVG7.5's 
 Anti-spyware component got disabled, so WD got turned back on behind my 
 back.

 I turned it off /again/, upgraded to AVG8.0, and AVG Anti-Spyware (and 
 Avti-Virus) were happy again.

 Then, I rebased again to 0x6500 (I had earlier tried 0x6300 in 
 desperation) and then I was able to bootstrap libtool-git.

I'm glad to read that this had a natural explanation.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

[ITA] glpk-4.21-1

Hi All,

as previously discussed 
glpk is one of the package needed to compile octave

it is also present in debian.

glpk/setup.hint
---
category: Math
requires: cygwin
sdesc: GLPK (GNU Linear Programming Kit)
ldesc: The GLPK (GNU Linear Programming Kit) package
is intended for solving large-scale linear programming
(LP), mixed integer programming (MIP), and other
related problems. It is a set of routines written in
ANSI C and organized in the form of a callable
library.

libglpk-devel/setup.hint
-
category: Math
requires: cygwin glpk
external-source: glpk
sdesc: GLPK (GNU Linear Programming Kit) development
libraries
ldesc: The GLPK (GNU Linear Programming Kit) package
is intended for solving large-scale linear programming
(LP), mixed integer programming (MIP), and other
related problems. It is a set of routines written in
ANSI C and organized in the form of a callable
library.

to download

wget -r
http://matzeri.altervista.org/cygwin/glpk/index.html

http://matzeri.altervista.org/cygwin/glpk/setup.hint
http://matzeri.altervista.org/cygwin/glpk/glpk-4.21-1-src.tar.bz2
http://matzeri.altervista.org/cygwin/glpk/glpk-4.21-1.tar.bz2
http://matzeri.altervista.org/cygwin/glpk/libglpk-devel
http://matzeri.altervista.org/cygwin/glpk/libglpk-devel/libglpk-devel-4.21-1.tar.bz2
http://matzeri.altervista.org/cygwin/glpk/libglpk-devel/setup.hint

 



  Inviato da Yahoo! Mail. 
La casella di posta intelligente.
http://it.docs.yahoo.com/mail/overview/index.html

[ITA] hdf5-1.6.7-1

Dear all,
I would like to adopt HDF5

Hdf5 is one of the package need to compile octave
it is also present in debian

hdf5/setup.hint

category: Archive Utils
requires: cygwin zlib
sdesc: HDF5 Hierarchical Data Format 
ldesc: HDF5 is a completely new Hierarchical Data
Format product consisting of a data format
specification and a supporting library implementation

libhdf5-devel/setup.hint
-
category: Archive Utils
requires: cygwin zlib hdf5
external-source: hfd5
sdesc: HDF5 Hierarchical Data Format (development
libraries) 
ldesc: HDF5 is a completely new Hierarchical Data
Format product consisting of a data format
specification and a supporting library implementation

To download

wget -r -np
http://matzeri.altervista.org/cygwin/hdf5/index.html

http://matzeri.altervista.org/cygwin/hdf5/setup.hint
http://matzeri.altervista.org/cygwin/hdf5/hdf5-1.6.7-1-src.tar.bz2
http://matzeri.altervista.org/cygwin/hdf5/hdf5-1.6.7-1.tar.bz2
http://matzeri.altervista.org/cygwin/hdf5/libhdf5-devel/libhdf5-devel-1.6.7-1.tar.bz2
http://matzeri.altervista.org/cygwin/hdf5/libhdf5-devel/setup.hint




  Tante idee per la salvaguardia del nostro Pianeta su Yahoo! For Good 
http://it.promotions.yahoo.com/forgood/environment.html

[ITA] qhull-2003.1-1

Hi All,

I would like to adopt Qhull, as it is one of the
packages needed to compile octave.
It is also present in debian

qhull/setup.int

sdesc: Qhull is a general dimension convex hull
program 
category: Math
requires: cygwin libqhull
ldesc: Qhull is a general dimension convex hull
program, 
  it also generates Delaunay triangulations, Voronoi
  diagrams, furthest-site Voronoi diagrams, and
halfspace 
  intersections about a point.

libqhull/setup.hint
---
sdesc: Qhull (convex hull program) Runtime 
category: Libs Math 
requires: cygwin 
external-source: qhull
ldesc: Qhull is a general dimension convex hull
program, 
  it also generates Delaunay triangulations, Voronoi
  diagrams, furthest-site Voronoi diagrams, and
halfspace 
  intersections about a point.

libqhull-devel/setup.hint
---
sdesc: Qhull ( convex hull program) development 
category: Libs Math
requires: cygwin qhull libqhull
external-source: qhull
ldesc: Qhull is a general dimension convex hull
program, 
  it also generates Delaunay triangulations, Voronoi
  diagrams, furthest-site Voronoi diagrams, and
halfspace 
  intersections about a point.

To download 
wget -r -np
http://matzeri.altervista.org/cygwin/qhull/index.html

http://matzeri.altervista.org/cygwin/qhull/libqhull/libqhull-2003.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/qhull/libqhull/setup.hint
http://matzeri.altervista.org/cygwin/qhull/libqhull-devel/libqhull-devel-2003.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/qhull/libqhull-devel/setup.hint
http://matzeri.altervista.org/cygwin/qhull/qhull-2003.1-1-src.tar.bz2
http://matzeri.altervista.org/cygwin/qhull/qhull-2003.1-1.tar.bz2
http://matzeri.altervista.org/cygwin/qhull/setup.hint





  Tante idee per la salvaguardia del nostro Pianeta su Yahoo! For Good 
http://it.promotions.yahoo.com/forgood/environment.html

SuiteSparse-3.1.0-1

Hi All,
I would like to adopt SuiteSparse

It is one of the packages need to compile octave,
it is also present in debian.

SuiteSparse/setup.hint
-
sdesc: SuiteSparse 
category: Libs Math
requires: cygwin 
ldesc: library and headers of SuiteSparse. Used to
compile Octave

libSuiteSparse-devel/setup.hint
--
sdesc: SuiteSparse (development libraries) 
category: Libs Math
requires: cygwin lapack
ldesc: library and headers of SuiteSparse. Used to
compile Octave



To download 
wget -r -np
http://matzeri.altervista.org/cygwin/suitesparse/index.html

http://matzeri.altervista.org/cygwin/suitesparse/libSuiteSparse-devel/libSuiteSparse-devel-3.1.0-1.tar.bz2
http://matzeri.altervista.org/cygwin/suitesparse/libSuiteSparse-devel/setup.hint
http://matzeri.altervista.org/cygwin/suitesparse/setup.hint
http://matzeri.altervista.org/cygwin/suitesparse/SuiteSparse-3.1.0-1-src.tar.bz2
http://matzeri.altervista.org/cygwin/suitesparse/SuiteSparse-3.1.0-1.tar.bz2



  Tante idee per la salvaguardia del nostro Pianeta su Yahoo! For Good 
http://it.promotions.yahoo.com/forgood/environment.html

findutils support in 1.7.0

2008-04-25 Thread Eric Blake


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've uploaded findutils-4.4.0-2 to release-2.  I've tested that birthtime
support works, and the code heavily exercises the new *at() functions.
However, I haven't yet tested whether the long path name support works,
but assume it does, because findutils includes some configure-time tests
to see what to support.  Also, it looks like long path names are currently
quadratic in behavior, as the configure-time test for whether getcwd()
returns accurate results on names longer than PATH_MAX took several
seconds to complete, whereas the same test on Linux is as fast as any of
the other configure checks.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgSnxcACgkQ84KuGfSFAYB72QCgwCDxAa1usUhTHEBkFriWmesR
GcUAmgN0ACaGvMSqcNgKx9C1CjKpZx/t
=P9Hb
-END PGP SIGNATURE-

src/winsup/cygwin ChangeLog fhandler.cc

2008-04-25 Thread corinna

CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED]   2008-04-25 16:50:29

Modified files:
winsup/cygwin  : ChangeLog fhandler.cc 

Log message:
* fhandler.cc (fhandler_base::open): *Only* handle SYSTEM and HIDDEN
attributes in FILE_OVERWRITE case.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4121r2=1.4122
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.cc.diff?cvsroot=srcr1=1.322r2=1.323

src/winsup/cygwin ChangeLog fhandler.cc

2008-04-25 Thread corinna

CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED]   2008-04-25 16:59:41

Modified files:
winsup/cygwin  : ChangeLog fhandler.cc 

Log message:
* fhandler.cc (fhandler_base::open): Move handling FILE_ATTRIBUTE_NORMAL
back to its old place.  Or it to file_attributes instead of setting it.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4122r2=1.4123
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.cc.diff?cvsroot=srcr1=1.323r2=1.324

src/winsup/cygwin ChangeLog postinstall

2008-04-25 Thread corinna

CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED]   2008-04-25 17:13:27

Modified files:
winsup/cygwin  : ChangeLog 
Removed files:
winsup/cygwin  : postinstall 

Log message:
* postinstall: Remove (Moved to base-cygwin package).

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4123r2=1.4124
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/postinstall.diff?cvsroot=srcr1=1.8r2=NONE

Re: wait.h

On Apr 24 17:44, Yaakov (Cygwin Ports) wrote:
 Corinna Vinschen wrote:
 | Thanks, applied.  I won't apply it to the 1.5 branch, though.  Only
 | really important bugfixes should go there.  1.5 DLLs are a dying species.

 Thank you.  (I'm a bit confused as to how endangered 1.5 is.)

It's already on the list of endangered species.  If all goes well, it's
the last year of the 1.5 series.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

How to run Cygwin from USB stick without admin access (was: Install cygwin in Win2K as nonadmin...)

2008-04-25 Thread Martin Fischer


   Thorsten Kampe writes:
   Date: Thu, 24 Apr 2008 13:06:02 +0200
   
   * Paul Domaskis (Tue, 22 Apr 2008 16:47:16 -0400)
   I will be using a standalone Win2K machine on which I will likely not
   have admin access.  Will this be a problem, if I choose to install
   only for the account of interest?
   
   No, I use that version exclusively on my machines (because I run Cygwin 
   from my USB stick).
   

Hi,

I tried running Cygwin from USB stick following the instructions of
Fergus Bonhard for CDs analogously
(http://www.cygwin.com/ml/cygwin/2003-07/msg01117.html referred to in
the FAQ), but was stopped by the necessity to perform the mount
command with admin rights.

What is your solution in general and with respect to that detail ?

Cheers

Martin
-- 
parozusa at web dot de


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to run Cygwin from USB stick without admin access

2008-04-25 Thread Fergus


 ... but was stopped by the necessity to perform
 the mount command with admin rights.

Hi, I use Cygwin the whole time from a mobile drive on home, work and 
other people's machines none of which have Cygwin installed (but they 
could have). The principles are the same as for CD-bound systems but 
with much more flexibility (size and write-ability). I'm afraid I have 
never found any difficulty using it on ancient W98 machines, and on 
machines running XP up to SP3 (and even Vista, now with SP1) but have 
never knowingly tried it on W2K. A big chunk of the startup (.cmd or 
.bat) file is devoted to preserving any pre-existing mounts and if you 
don't need to do this the startup file is very brief and straightforward 
(isn't it? in hundreds of contexts on different machines I suppose I 
could even now be missing some obvious difficulty) as follows (where h: 
is your USB drivename):


  @h:\bin\mount -buf h:/bin /usr/bin
  @h:\bin\mount -buf h:/lib /usr/lib
  @h:\bin\mount -buf h:/ /
  @h:\bin\mount -bufc /
  @set SHELL=/bin/bash
  @set HOME=/home/user # OR WHATEVER YOUR $HOME IS
  @start /wait h:\bin\bash
  @set HOME=
  @set SHELL=

This script can be rendered considerably more sophisticated but this 
would be a good starting point if you are bug-hunting. Can you say where 
it breaks down, for you?


Fergus



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Install cygwin in Win2K as nonadmin from CD make from WinXP

2008-04-25 Thread Thorsten Kampe

* Paul Domaskis (Thu, 24 Apr 2008 21:27:04 -0400)
 Thorsten Kampe thorsten at thorstenkampe dot de wrote:
  * Paul Domaskis (Tue, 22 Apr 2008 16:47:16 -0400) wrote:
  I will be using a standalone Win2K machine on which I will likely
  not have admin access.  Will this be a problem, if I choose to
  install only for the account of interest?
 
  No, I use that version exclusively on my machines (because I run
  Cygwin from my USB stick).
 
 Wow.  That's cool.  For any one machine, I guess you must ensure that
 the stick maps to the same letter drive whenever you plug it in,
 right?  (I'm guessing this because the path is specified in the user's
 Windows path).

I've got a batch script that sets the mount points dynamically.

Thorsten


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Looking for basic documentation on Cygwin and Serial Ports

2008-04-25 Thread Dave Korn

Nefastor wrote on 24 April 2008 23:08:

 case : My machine has two serial port, one on the MoBo and a USB-serial
 adapter, yet Windows calls them COM1 and COM3. 

  Or /dev/ttyS0 and /dev/ttyS2, as they'll be known to cygwin.

 Speaking of Windows' DM, it's rather quirky on the serial
 ports : I noticed
 that if I unplug my USB cable (COM3) and try to change the
 name of COM1, in
 the drop down box COM3 is listed as in use :confused: %-|.

  RGH[*]!  FTDIchip are the bane of my life at the moment.  Buggy drivers.
I hate them so much spit.

 - is there a fixed relationship between COM port number X
 and dev/ttyS
 number Y, such as Y = X - 1 ? 

  Yes.

 For instance, if I change my
 COM port number
 from 3 to 7, will the dev/ttyS number go from 2 to 6, 

  Yes.

 Additionally, can you point me to documentation on how to
 retrieve device /
 driver info from my program ? That way, worst case scenario,
 I can have the
 program look for the correct port on its own.

  Don't understand what kind of device/driver info you mean here.  You might
be able to use the win32 pnp api functions.

cheers,
  DaveK

[*] - I just got back from rebooting a testrig that locked up due to buggy
ftdichip drivers at about the twentytwo-hour point into a twentyseven-hour
testrun.  I am not happy.
-- 
Can't think of a witty .sigline today



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

- stdin read problem

2008-04-25 Thread Alexey Zakharov

Hi,

I've attached simple cpp program which demonstrates the problem.
The program works fine from cmd.exe, but fails when started from cygwin.

The program does the following:
- The main thread creates a helper thread which reads stdin and prints
the data read.
- stdin is read via ReadFile() Win32 API function.
- At the end of the main function, the main thread calls CloseHandle()
func for the stdin. It causes the ReadFile() function to return, and
the helper thread to finish. From cmd the program works as described.
- Under Cygwin  the program works differently. The helper thread is
not finished, because it doesn't exit from the ReadFile() func. The
main thread waits for the helper thread's completion during 1 sec,
then it calls TerminateThread() Win32 API func.

When I start the program from cmd, I see the following output:
read_stdin_example.exe
Stdin_Reader_Thread has been completed

When I start the program from Cygwin, I see:
$ ./read_stdin_example.exe
Stdin_Reader_Thread has NOT been completed. So, it will be terminated.

I believe that this information would be enough to investigate and fix
the problem.
If you need more information or have questions, feel free to contact me.

Have a nice day!
~Alexey

#include stdio.h
#include windows.h

#define MY_BUF_SIZE 1024

DWORD WINAPI read_stdin(LPVOID lpParameter)
{
BOOL bResult = FALSE;
char szBuf[MY_BUF_SIZE] = ;
int nIndex = 0;
DWORD nNumOfBytesRead = 0;

HANDLE hStdin = GetStdHandle(STD_INPUT_HANDLE);
if (hStdin == NULL || hStdin == INVALID_HANDLE_VALUE)
{
printf(GetStdHandle failed for STD_INPUT_HANDLE\n);
exit(2);
}

nIndex = 0;
for (;;)
{
nNumOfBytesRead = 0;
szBuf[nIndex] = '\0';
bResult = ReadFile(hStdin, szBuf[nIndex], 1, nNumOfBytesRead, NULL);

if (bResult)
{
if (nNumOfBytesRead == 0)
{
// End of the file was reached

// Print the data read if they exist
if (nIndex  0)
{
printf(Input data = \%s\\n, szBuf);
}

break;
}

if ( (szBuf[nIndex] == '\n') || (nIndex == MY_BUF_SIZE - 1) )
{
// End of the input has been detected
// Print the input data
printf(Input data = \%s\\n, szBuf);

// Reset the index back to the beginning of the input buffer
nIndex = 0;
}
else
{
// Increment the index and continue the reading
++nIndex;
}
}
else
{
DWORD dwErrorCode = GetLastError();

printf(ReadFile failed = LastErrorCode = %d\n, dwErrorCode);
exit(3);
}

} // infinite for cycle

return 0;
} // read_stdin

int main(int argc, char *argv[])
{
BOOL bResult = FALSE;

DWORD dwThreadID = 0;
HANDLE hStdinReaderThread = CreateThread(
NULL, 0, (LPTHREAD_START_ROUTINE)read_stdin, NULL, 0, dwThreadID);
if (!hStdinReaderThread)
{
printf(CreateThread failed\n);
exit(1);
}

// Simulate work in the main thread
Sleep(1000);

// Close the stdin = the stdin reader thread should exit in that case
CloseHandle(GetStdHandle(STD_INPUT_HANDLE));
if (WaitForSingleObject(hStdinReaderThread, 1000) != WAIT_OBJECT_0)
{
printf(Stdin_Reader_Thread has NOT been completed. So, it will be 
terminated.\n);
TerminateThread(hStdinReaderThread, 1);
}
else
{
printf(Stdin_Reader_Thread has been completed\n);
}
CloseHandle(hStdinReaderThread);

return 0;
} // main
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

- stdin read problem

2008-04-25 Thread Alexey Zakharov

Hi,

I've attached simple cpp program which demonstrates the problem.
The program works fine from cmd.exe, but fails when started from cygwin.


The program does the following:
- The main thread creates a helper thread which reads stdin and prints
the data read.
- stdin is read via ReadFile() Win32 API function.
- At the end of the main function, the main thread calls CloseHandle()
func for the stdin. It causes the ReadFile() function to return, and
the helper thread to finish. From cmd the program works as described.
- Under Cygwin  the program works differently. The helper thread is
not finished, because it doesn't exit from the ReadFile() func. The
main thread waits for the helper thread's completion during 1 sec,
then it calls TerminateThread() Win32 API func.


When I start the program from cmd, I see the following output:
read_stdin_example.exe
Stdin_Reader_Thread has been completed

When I start the program from Cygwin, I see:
$ ./read_stdin_example.exe
Stdin_Reader_Thread has NOT been completed. So, it will be terminated.

I believe that this information would be enough to investigate and fix
the problem.
If you need more information or have questions, feel free to contact me.

Have a nice day!
~Alexey

#include stdio.h
#include windows.h

#define MY_BUF_SIZE 1024

DWORD WINAPI read_stdin(LPVOID lpParameter)
{
BOOL bResult = FALSE;
char szBuf[MY_BUF_SIZE] = ;
int nIndex = 0;
DWORD nNumOfBytesRead = 0;

HANDLE hStdin = GetStdHandle(STD_INPUT_HANDLE);
if (hStdin == NULL || hStdin == INVALID_HANDLE_VALUE)
{
printf(GetStdHandle failed for STD_INPUT_HANDLE\n);
exit(2);
}

nIndex = 0;
for (;;)
{
nNumOfBytesRead = 0;
szBuf[nIndex] = '\0';
bResult = ReadFile(hStdin, szBuf[nIndex], 1, nNumOfBytesRead, NULL);

if (bResult)
{
if (nNumOfBytesRead == 0)
{
// End of the file was reached

// Print the data read if they exist
if (nIndex  0)
{
printf(Input data = \%s\\n, szBuf);
}

break;
}

if ( (szBuf[nIndex] == '\n') || (nIndex == MY_BUF_SIZE - 1) )
{
// End of the input has been detected
// Print the input data
printf(Input data = \%s\\n, szBuf);

// Reset the index back to the beginning of the input buffer
nIndex = 0;
}
else
{
// Increment the index and continue the reading
++nIndex;
}
}
else
{
DWORD dwErrorCode = GetLastError();

printf(ReadFile failed = LastErrorCode = %d\n, dwErrorCode);
exit(3);
}

} // infinite for cycle

return 0;
} // read_stdin

int main(int argc, char *argv[])
{
BOOL bResult = FALSE;

DWORD dwThreadID = 0;
HANDLE hStdinReaderThread = CreateThread(
NULL, 0, (LPTHREAD_START_ROUTINE)read_stdin, NULL, 0, dwThreadID);
if (!hStdinReaderThread)
{
printf(CreateThread failed\n);
exit(1);
}

// Simulate work in the main thread
Sleep(1000);

// Close the stdin = the stdin reader thread should exit in that case
CloseHandle(GetStdHandle(STD_INPUT_HANDLE));
if (WaitForSingleObject(hStdinReaderThread, 1000) != WAIT_OBJECT_0)
{
printf(Stdin_Reader_Thread has NOT been completed. So, it will be 
terminated.\n);
TerminateThread(hStdinReaderThread, 1);
}
else
{
printf(Stdin_Reader_Thread has been completed\n);
}
CloseHandle(hStdinReaderThread);

return 0;
} // main
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: - stdin read problem

2008-04-25 Thread Dave Korn

Alexey Zakharov wrote on 25 April 2008 15:48:

 The program does the following:
 - The main thread creates a helper thread which reads stdin and prints
 the data read. 
 - stdin is read via ReadFile() Win32 API function.

  No, that's *not* stdin.  Stdin is file descriptor zero, and you aren't
reading from Cygwin's fd zero.  You just broke Cygwin's ptty implementation by
going behind its back and stealing its input.

  Just for comparison, this wouldn't work on Linux, would it?  Cygwin is a
Linux emulation layer.  Linux doesn't support calls to the Win32 api ReadFile,
obviously enough, so Cygwin doesn't either.

  In particular, it is not AFAIK a supported mode of operation to intersperse
Cygwin's emulated POSIX syscalls with arbitrary calls to the Win32 api that
Cygwin expects to have to itself in order to perform the emulation.

  You /may/ be able to get your code to work as you expect when launched from
a Cygwin shell running in a DOS prompt console by using the CYGWIN=notty
environment variable option (if you're currently using CYWIN=tty, that is),
but I don't think it'll ever work in a rxvt or X console.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Looking for basic documentation on Cygwin and Serial Ports

2008-04-25 Thread Nefastor



NightStrike wrote:
 
 What motherboard do you have?  It's always possible that there is a
 riser pinout for a serial port somewhere in the front of the board for
 connection to a front panel mount.
 

No, I checked for that. Besides, this port would appear in Windows' device
manager even if it wasn't brought out of the board. I also explored the
possibility of a serial port used internally to connect to some type of
monitoring chip, but nothing there either. The board is a fairly old
micro-ATX with fairly limited connectivity (hence the USB-to-serial cable).

Nefastor
-- 
View this message in context: 
http://www.nabble.com/Looking-for-basic-documentation-on-Cygwin-and-Serial-Ports-tp16827997p16896990.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Looking for basic documentation on Cygwin and Serial Ports

2008-04-25 Thread Nefastor

Thanks Dave, I kinda suspected the FTDI drivers for the COM3 issue (I've seen
worse : once, the COM port number would be incremented every time the cable
was unplugged and replugged). Unfortunately I'm stuck with FTDI chips as
they are, AFAIK, the only USB-to-serial adapters I can buy as chips and
solder myself.

The device and/or driver info I was asking about is just that : whatever
system variable(s) hold the information about the hardware present on the
PC. I'm no Windows programmer (though not for lack of training), I suppose I
can find my way from the win32 pnp API. Thank you for the pointer.

The program I'm trying to write is for an autonomous machine. Normally I'd
design my own single-board computer for maximum reliability but this time I
need the functionality of an OS like Windows or Linux. I'm trying to make
the behavior of that OS as predictable as possible, because the end-product
will have to operate away from someone who could CTRL-ALT-DEL it (and it
would really be overkill to install VNC on my application :-U)

Thanks for all the info, everyone :-D. I'm gonna try a few things and get
back to you.

Nefastor
--
View this message in context:
http://www.nabble.com/Looking-for-basic-documentation-on-Cygwin-and-Serial-Ports-tp16827997p16897467.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

RE: Looking for basic documentation on Cygwin and Serial Ports

2008-04-25 Thread Dave Korn

Nefastor wrote on 25 April 2008 17:26:

 Thanks Dave, I kinda suspected the FTDI drivers for the COM3 issue

  One tip I've learned is never, ever, ever, unplug them while you're still
running your terminal software (or whatever) and it's got the port open.
Disconnect, or exit the application, or you're screwed until you reboot.

  However, discussion of their many and varied flaws is getting fairly far
off-topic because it's not cygwin-specific; if you'd like to pursue that
angle, we should TITTTL.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Imagemagick : montage errors

2008-04-25 Thread Sivaram Neelakantan

I updated the imagemagick package to the latest version through setup
and now my scripts are failing with the following error.

$ montage -version
Version: ImageMagick 6.4.0 04/17/08 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

$ montage ./Wip1.png ./Wip_30_Day.png -tile 1x2 -geometry 100x100%
 ./w.png   
montage: unable to read font
 `/usr/lib/ImageMagick-6.4.0/config//usr/share/fonts/corefonts/arial.ttf'.

The path separator is missing.  I have a stock install with little or
 no customisations in *my* login profiles that has the above paths.


 sivaram
 -- 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Looking for basic documentation on Cygwin and Serial Ports


Dave Korn wrote:


  RGH[*]!  FTDIchip are the bane of my life at the moment.  Buggy drivers.
I hate them so much spit.

[*] - I just got back from rebooting a testrig that locked up due to buggy
ftdichip drivers at about the twentytwo-hour point into a twentyseven-hour
testrun.  I am not happy.


Wow. I've been using them too, but have had no problems at all 
(WinXPsp2) from native consoles (no cygwin involved, if that matters). 
Then again, I wasn't trying to run 27 hour tests.


--
Chuck



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Add OpenSC packages to cygwin?

2008-04-25 Thread Alon Bar-Lev

Hello,

We have just finished to update OpenSC's trunks [1], [2], [3] to
support mingw cross compile and cygwin.

tarballs are available at [4], [5], [6].

Any feedback is appreciated.

Is anyone interested in maintaining a cygwin packages for OpenSC projects?

Please CC me as I am not subscribed to this list.

Thanks,
Alon Bar-Lev.

[1] http://www.opensc-project.org/svn/opensc/trunk
[2] http://www.opensc-project.org/svn/libp11/trunk
[3] http://www.opensc-project.org/svn/engine_pkcs11/trunk
[4] http://alon.barlev.googlepages.com/opensc-0.11.4-svn.tar.gz
[5] http://alon.barlev.googlepages.com/libp11-0.2.3-svn.tar.gz
[6] http://alon.barlev.googlepages.com/engine_pkcs11-0.1.4-svn.tar.gz

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

fstatat support

2008-04-25 Thread Eric Blake

In trying to build findutils for cygwin 1.7.0, I'm running into:

fts.c: In function `fts_stat':
fts.c:1395: warning: passing arg 3 of `fstatat' from incompatible pointer type

Is there any reason why you declared fstatat to take struct __stat64 * instead 
of struct stat like all the other *stat functions in sys/stat.h?

-- 
Eric Blake



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

cygport missing features after 0.3.9 [Was: Re: [ANNOUNCEMENT] Updated: inetutils-1.5-3]


I just uploaded 0.3.9, so you should be able to start
porting your customized .cygport's for it.

Are there any other features you still need?


Dunno. I'll port forward my existing patches (except the relocatable 
stuff), and then see.  It's when I'm forward porting that I usually 
discover what's been obsoleted, and what needs to be reworked, among my 
patches.


Offhand, I'd say:

 (1) being able to specify a -d path to cvs that differs from 
CVS_MODULE (used by libgeotiff; the actual libgeotiff source is not a 
module itself, but is buried inside the 'geotiff' module. I don't want 
that other stuff, AND I don't want src/geotiff/libgeotiff, nor the 
libgeotiff-tarball having geotiff/ in it, where geotiff/ is otherwise 
empty.)


 (2) a post install hook (used by rxvt-unicode)

 (3) custom-cmds patch (otherwise running the cvs testsuite all-at-once 
is just too painful, since there is no -k option...it's shell script 
driven, not makefile driven)


THEN I'll think about how to port the bitrotted relocatable stuff.  But 
that may just be too ugly and intrusive, and not useful enough for 
anything other than libiconv and gettext, to push into the official 
cygport. I don't mind maintaining THAT out-of-tree; it was just that 
/plus/ all the other patches that made me want to take up a more serene 
hobby, like basejumping.


--
Chuck

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

SetErrorMode (SEM_FAILCRITICALERRORS) not working on Vista?

2008-04-25 Thread cygwin

I was running the libtool-2.2 testsuite on Vista [32bit Home Premium] 
(cygwin-1.5.25-12), and ran into something I thought was long dead: I 
kept getting popup windows like:


X.exe has stopped working
Windows is checking for a solution to the problem...

which after about five seconds was replaced by:

X.exe has stopped working
A problem has caused the program to stop working correctly.
Windows will close the program and notify you if a solution is available.

Which would then wait patiently for me to click 'Close Program' -- 
meanwhile, the testsuite was also suspended.  This happened


six times [hell.exe] in demo-relink.test
six times [depdemo.exe] in depdemo-relink.test

which are part of the libtool-1.5-derived old test suite, and

twelve times [m-static.exe] in 27: static linking flags for program
twelve times [m-static-libtool-libs.exe] in (the same test)
twelve more times [m-static.exe] in (the same test)
twelve more times [m-static-libtool-libs.exe] in (the same test)

which are part of the new autotest testsuite in libtool-2.2.

I think the 6x repetitiveness is cygwin's 'retry' algorithm kicking in. 
When an app fails to load, cygwin tries again five more times 
(modifiable using CYGWIN=proc_retry:n).


So I understand why there are (multiples of) six failures each -- these 
relinked versions in the old test suite (and the occurances in the new 
test suite) are expected to fail with either dll-not-found or 
missing-symbol errors.  But Cygwin calls

  SetErrorMode (SEM_FAILCRITICALERRORS)
so I don't understand why I'm getting the popups at all.

I do /not/ see these popups on WinXPsp2 (cygwin-1.5.25-12)

--
Chuck

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Add OpenSC packages to cygwin?

2008-04-25 Thread Yitzchak Scott-Thoennes

On Fri, April 25, 2008 2:16 pm, Alon Bar-Lev wrote:
 Is anyone interested in maintaining a cygwin packages for OpenSC
 projects?

To whit:

http://www.opensc-project.org/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

OCEnvNlsCreate error using DBD::Oracle 1.21 on Cygwin 1.5

2008-04-25 Thread Dunston Rocks

Hi
Firstly, thanks for continuing to work with me on this.
Here's my script. and the output. 
I am able to connect to all databases in TNS_ADMIN/tnsnames.ora from the cygwin 
prompt, but  am unable to get the script to connect.
I
have all the below-mentioned environment variables set in the Windows
environment as well, which cygwin picks up at start-up as well.
Regardless, I set them in the script as well, as shown below.
I
have tried all variations of the DBI-connect statement mentioned in
the perldocs in the script below, but continue to encounter the
OCIEnvNlsCreate error. 

It seems to be a permissions issue, but I don't know where to look or how to 
fix it. 
*** SCRIPT *
#!/usr/bin/perl

use strict;
use DBI;

print Testing connection to DEV \n;
$ENV{ORACLE_SID}= 'CBDEV';
$ENV{TWO_TASK}= 'CBDEV';
$ENV{TNS_ADMIN}= 'C:\oracle\product\10.2.0\client_2\NETWORK\ADMIN\tnsnam
es.ora'; # Also tried replacing these with POSIX-Style paths
$ENV{ORACLE_HOME}  = C:\oracle\product\10.2.0\client_2;
$ENV{NLS_LANG}  = AMERICAN_AMERICA.WE8DEC;
$ENV{ORA_NLS}  = $ENV{ORACLE_HOME}./ocommon/nls/admin/data;
$ENV{LD_LIBRARY_PATH}  = $ENV{ORACLE_HOME}./lib;
$ENV{ORA_NLS10}= '/oracle/product/10.2.0/client_2/nls/data';

my @driver_names = DBI-available_drivers;

foreach my $driver_name (@driver_names) {

print $driver_name,\n;
my %attr;

my  @data_sources = DBI-data_sources($driver_name, \%attr);
foreach (@data_sources) {
print Data Source: ,$_,\n;
   if ($_ =~/CBDEV) {
my $cHash = getCytoband(); # fails with OCI Env NlsError
here.
 }
}
}

sub getCytoband() {
my($name, $id);
my %nameHash;

my $dbh = DBI-connect('DBI:Oracle:CBDEV', 'dunston', 'rocks') || die  Error 
.DBI-errstr;
my $sql = qq(SELECT * from GENE_NAMES);
my $sth = $dbh-prepare($sql);
$sth-execute();

$sth-bind_columns(\$id, \$name);

while($sth-fetch()) {

$name=~s/\s+//g;
$id=~s/\s+//g;

$nameHash{$name}=$id;
print Name : $name , $nameHash{$name}, \n;
}
return \%nameHash;
}

exit;

*** OUTPUT *

DBM
*DBI:DBM:f_dir=.cpan
*DBI:DBM:f_dir=.texmf
*DBI:DBM:f_dir=acroread
*DBI:DBM:f_dir=apache-ant-1.6.5
*DBI:DBM:f_dir=apache-ant-1.7.0-bin
*DBI:DBM:f_dir=AppName
*DBI:DBM:f_dir=autorun
*DBI:DBM:f_dir=caBIO
*DBI:DBM:f_dir=cabioApp
*DBI:DBM:f_dir=cygwin
*DBI:DBM:f_dir=dell
*DBI:DBM:f_dir=Documents and Settings
*DBI:DBM:f_dir=Downloads
*DBI:DBM:f_dir=drivers
*DBI:DBM:f_dir=httpd-2.2.8
*DBI:DBM:f_dir=i386
*DBI:DBM:f_dir=indexes
*DBI:DBM:f_dir=jboss-4.0.4.GA
*DBI:DBM:f_dir=jboss-4.0.5.GA
*DBI:DBM:f_dir=MSOCache
*DBI:DBM:f_dir=MyApp
*DBI:DBM:f_dir=NALCache
*DBI:DBM:f_dir=NOVELL
*DBI:DBM:f_dir=oracle
*DBI:DBM:f_dir=Perl
*DBI:DBM:f_dir=Perl-Critic-1.082
*DBI:DBM:f_dir=Perl-Tidy-20071205
*DBI:DBM:f_dir=Program Files
*DBI:DBM:f_dir=RECYCLER
*DBI:DBM:f_dir=ruby
*DBI:DBM:f_dir=System Volume Information
*DBI:DBM:f_dir=Tcl
*DBI:DBM:f_dir=Temp
*DBI:DBM:f_dir=WINDOWS
*DBI:DBM:f_dir=.
ExampleP
*dbi:ExampleP:dir=.
File
*DBI:File:f_dir=.cpan
*DBI:File:f_dir=.texmf
*DBI:File:f_dir=acroread
*DBI:File:f_dir=apache-ant-1.6.5
*DBI:File:f_dir=apache-ant-1.7.0-bin
*DBI:File:f_dir=AppName
*DBI:File:f_dir=autorun
*DBI:File:f_dir=caBIO
*DBI:File:f_dir=cabioApp
*DBI:File:f_dir=cygwin
*DBI:File:f_dir=dell
*DBI:File:f_dir=Documents and Settings
*DBI:File:f_dir=Downloads
*DBI:File:f_dir=drivers
*DBI:File:f_dir=httpd-2.2.8
*DBI:File:f_dir=i386
*DBI:File:f_dir=indexes
*DBI:File:f_dir=jboss-4.0.4.GA
*DBI:File:f_dir=jboss-4.0.5.GA
*DBI:File:f_dir=MSOCache
*DBI:File:f_dir=MyApp
*DBI:File:f_dir=NALCache
*DBI:File:f_dir=NOVELL
*DBI:File:f_dir=oracle
*DBI:File:f_dir=Perl
*DBI:File:f_dir=Perl-Critic-1.082
*DBI:File:f_dir=Perl-Tidy-20071205
*DBI:File:f_dir=Program Files
*DBI:File:f_dir=RECYCLER
*DBI:File:f_dir=ruby
*DBI:File:f_dir=System Volume Information
*DBI:File:f_dir=Tcl
*DBI:File:f_dir=Temp
*DBI:File:f_dir=WINDOWS
*DBI:File:f_dir=.
Gofer
Oracle
*dbi:Oracle:CBDEV
DBI
connect('CBDEV','dunston',...) failed: ERROR OCIEnvNlsCreate. Check
ORACLE_HOME env var, NLS settings, permissions, etc. at tmp.pl line 26
Error ERROR OCIEnvNlsCreate. Check ORACLE_HOME env var, NLS settings, 
permissions, etc. at tmp.pl line 26.

I would greatly appreciate your help in identifying the problem, if possible!!!

Thanks much!


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


--
Unsubscribe info:

Re: [ mingw-Patches-1789093 ] Modernize mingw10.dll build procedure