binutils 20021107-2
Hmm, a new ?bug? in binutils: Linking a g++-2 compiled program, with a g++-2 compiled dll (line breaks and blank lines added for clarity) RobertC@LIFELESSAMD ~/src/barch/build make /bin/bash ./libtool --mode=link g++-2 -g -O2 -o get-archive-name.exe src/get-archive-name.o src/Archive.la /usr/local/lib/libgetopt++.la -lm -lboost_regex g++-2 -g -O2 -o get-archive-name.exe src/get-archive-name.o src/.libs/Archive.a -L/usr/lib -L/usr/lib/w32api -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10 -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc /usr/local/lib /libgetopt++.dll.a -lstdc++-2 -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -lboost_regex -L/usr/local/lib -L/usr/local/lib /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/libstdc++-2.a(filebuf.o)(.text +0x2a8): filebuf.cc: multiple definition of `filebuf::~filebuf(void)' /usr/local/lib/libgetopt++.dll.a(d31.o)(.text+0x0): first defined here /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/libstdc++-2.a(streambuf.o) (.text+0x35c):streambuf.cc: multiple definition of `streambuf::sungetc(void)' /usr/local/lib/libgetopt++.dll.a(d000485.o)(.text+0x0): first defined here collect2: ld returned 1 exit status make: *** [get-archive-name.exe] Error 1 -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Problem with Win32/UNIX character set
Hello. I seem to be able to compile and run a problem fine, but when I run it, I notice it uses a UNIX character set instead of the DOS character set (I do NOT mean the endline characters - I mean the character set in general), so certain things (ASCII art mainly) look very messed up. How do I get this program to use the DOS character set? Is there an option for this in CygWin, do I have to #define something? Thanks in advance, DJHyperbyte -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
re: binutils 20021107-2
Hello Robert By default symbols in libstdc++.a are excluded when doing --export-all, to protect against this type of error. However, ld/pe-dll.c knows nothing about libstdc++-2.a. So those symbols do get exported ... and cause the usual problems with multiple definitions. Quick solution: Try --exclude-libs=libstdc++-2.a Danny Robert Collins wrote: Hmm, a new ?bug? in binutils: Linking a g++-2 compiled program, with a g++-2 compiled dll (line breaks and blank lines added for clarity) RobertC@LIFELESSAMD ~/src/barch/build make /bin/bash ./libtool --mode=link g++-2 -g -O2 -o get-archive-name.exe src/get-archive-name.o src/Archive.la /usr/local/lib/libgetopt++.la -lm -lboost_regex g++-2 -g -O2 -o get-archive-name.exe src/get-archive-name.o src/.libs/Archive.a -L/usr/lib -L/usr/lib/w32api -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10 -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc -lgcc /usr/local/lib /libgetopt++.dll.a -lstdc++-2 -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -lboost_regex -L/usr/local/lib -L/usr/local/lib /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/libstdc++-2.a(filebuf.o)(.text +0x2a8): filebuf.cc: multiple definition of `filebuf::~filebuf(void)' /usr/local/lib/libgetopt++.dll.a(d31.o)(.text+0x0): first defined here /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-10/libstdc++-2.a(streambuf.o) (.text+0x35c):streambuf.cc: multiple definition of `streambuf::sungetc(void)' /usr/local/lib/libgetopt++.dll.a(d000485.o)(.text+0x0): first defined here collect2: ld returned 1 exit status make: *** [get-archive-name.exe] Error 1 http://careers.yahoo.com.au - Yahoo! Careers - 1,000's of jobs waiting online for you! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: openssl-0.9.6g-2, openssl-devel-0.9.6g-2
I've updated the version of OpenSSL to 0.9.6g-2.
This also includes the openssl-devel package.
OpenSSL is now compiled using the -fno-builtin-memset setting which
prevents gcc from inlining and then optimizing away the memset(3) call.
This is a potential measure against keeping cleartext keys, passphrases
and passwords in memory accidentally.
To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page. This downloads setup.exe to your
system. Once you've downloaded setup.exe, run it and select "Net"
("Devel" for the openssl-devel package) and then click on the appropriate
field until the above announced version number appears if it is not
displayed already.
If you have questions or comments, please send them to the Cygwin
mailing list at: [EMAIL PROTECTED] . I would appreciate it if you would
use this mailing list rather than emailing me directly. This includes
ideas and comments about the setup utility or Cygwin in general.
If you want to make a point or ask a question, the Cygwin mailing list
is the appropriate place.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:
[EMAIL PROTECTED]
If you need more information on unsubscribing, start reading here:
http://sources.redhat.com/lists.html#unsubscribe-simple
Please read *all* of the information on unsubscribing that is available
starting at this URL.
I implore you to READ this information before sending email about how
you "tried everything" to unsubscribe. In 100% of the cases where
people were unable to unsubscribe, the problem was that they hadn't
actually read and comprehended the unsubscribe instructions.
If you need to unsubscribe from cygwin-announce or any other mailing
list, reading the instructions at the above URL is guaranteed to
provide you with the info that you need.
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developermailto:cygwin@;cygwin.com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: OpenSSH-3.5p1-2
I've updated the version of OpenSSH to 3.5p1-2. This version provides several fixes: - ssh-host-config now creates sshd_config according to the latest changes to OpenSSH. - The 3.5-1 version missed the patch to the 3.4-5 version, which figured the ntsec default setting by the API minor version number. For some reason this patch never made it into the official sources. - OpenSSH is now compiled using the -fno-builtin-memset setting which prevents gcc from inlining and then optimizing away the memset(3) call. This is a potential measure against keeping cleartext keys, passphrases and passwords in memory accidentally. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Once you've downloaded setup.exe, run it and select "Net" and then click on the appropriate field until the above announced version number appears if it is not displayed already. If you have questions or comments, please send them to the Cygwin mailing list at: [EMAIL PROTECTED] . I would appreciate it if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question, the Cygwin mailing list is the appropriate place. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. I implore you to READ this information before sending email about how you "tried everything" to unsubscribe. In 100% of the cases where people were unable to unsubscribe, the problem was that they hadn't actually read and comprehended the unsubscribe instructions. If you need to unsubscribe from cygwin-announce or any other mailing list, reading the instructions at the above URL is guaranteed to provide you with the info that you need. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:cygwin@;cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Jonathan FREESON/dassault-systemes is out of the office.
I will be out of the office starting 11/08/2002 and will not return until 11/11/2002. I will respond to your message when I return. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
re: binutils 20021107-2
On Sat, 2002-11-09 at 21:59, Danny Smith wrote: > Hello Robert > > By default symbols in libstdc++.a are excluded when doing --export-all, to > protect against this type of error. > > However, ld/pe-dll.c knows nothing about libstdc++-2.a. So those symbols do > get exported ... and cause the usual problems with multiple definitions. > > Quick solution: Try --exclude-libs=libstdc++-2.a > Got it in one. Should this be in the g++-2 specs? Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Bash 2.05b.04 - shopt extglob not working?
Isn't this supposed to work under Cygwin bash? I have "shopt extglob"
enabled.
Jari
a=new;
case $a in
-d) echo 1 ;;
@(add|new)) echo 2 ;;
esac
root@W2KPICASSO:~/config/shell/bash/complete$ bash -x ~/tmp/test.sh
+ bash -x ~/tmp/test.sh
+ a=new
/cygdrive/e/home/jaalto/tmp/t3.sh: line 5: syntax error near unexpected token `('
/cygdrive/e/home/jaalto/tmp/t3.sh: line 5: `@(add|new)) echo 2 ;;'
root@W2KPICASSO:~/config/shell/bash/complete$ shopt
+ shopt
cdable_vars off
cdspell off
checkhash off
checkwinsizeoff
cmdhist on
dotglob off
execfailoff
expand_aliases on
extglob on
histreedit off
histappend off
histverify off
hostcompleteon
huponexit off
interactive_commentson
lithist off
login_shell off
mailwarnoff
no_empty_cmd_completion off
nocaseglob off
nullgloboff
progcompon
promptvars on
restricted_shelloff
shift_verbose off
sourcepath on
xpg_echooff
--
http://tiny-tools.sourceforge.net/
Swatch @time http://www.ryanthiessen.com/swatch/resources.htm
Convert @time http://www.mir.com.my/iTime/itime.htm
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: patch.exe crashed on cygwin-1.3.15-2 (ATTN: cygwin patch maintainer!)
Corinna Vinschen <[EMAIL PROTECTED]> wrote: > On Sat, Nov 09, 2002 at 02:43:55AM -0500, Chris Faylor wrote: >> And, then there's the fact that the patch file that you just >> uploaded is exactly the same size as the previous one... > > Am I up too early this morning?!? I checked it on my local copy and > it was in fact gzip'd: > > $ ls -l patch-2.5-3-src.tar.bz2 > -rw-r--r--1 corinna users 144570 Feb 20 2002 > patch-2.5-3-src.tar.bz2 > > So I converted it to bzip'd: > > $ ls -l patch-2.5-3-src.tar.bz2 > -rw-r--r--1 corinna root 118074 Nov 9 07:56 > patch-2.5-3-src.tar.bz2 > > and uploaded it to cygwin.com. Hmm, probably somebody already > converted it on cygwin.com months ago... Yes, that makes sense. I've been transferring my Cygwin package cache from machine to machine with me since I started using Cygwin. So its quite possible that the patch src I have was downloaded as early as 2000. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
Robert Collins wrote:
On Sat, 2002-11-09 at 21:59, Danny Smith wrote:
Hello Robert
By default symbols in libstdc++.a are excluded when doing --export-all, to
protect against this type of error.
However, ld/pe-dll.c knows nothing about libstdc++-2.a. So those symbols do
get exported ... and cause the usual problems with multiple definitions.
Quick solution: Try --exclude-libs=libstdc++-2.a
Got it in one. Should this be in the g++-2 specs?
Nope. Chris should apply the attached patch to binutils and re-release.
It's surprising we didn't catch this when gcc-3.x/gcc2-2.95 were
getting their shakedown this summer. Oh well.
Also, Chris, you could take the opportunity of binutils-20021107-3 to
apply Egor's remaining patches... :-)
--Chuck
Index: pe-dll.c
===
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.45
diff -u -r1.45 pe-dll.c
--- pe-dll.c6 Nov 2002 19:36:20 - 1.45
+++ pe-dll.c9 Nov 2002 17:27:42 -
@@ -141,6 +141,7 @@
static struct sec *edata_s, *reloc_s;
static unsigned char *edata_d, *reloc_d;
static size_t edata_sz, reloc_sz;
+static int runtime_pseudo_relocs_created = 0;
typedef struct
{
@@ -234,6 +235,8 @@
{ "libg2c.", 7 },
{ "libsupc++.", 10 },
{ "libobjc.", 8 },
+ { "libstdc++-2.", 12 },
+ { "libg2c-2.", 9 },
{ NULL, 0 }
};
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
Charles Wilson wrote:
Nope. Chris should apply the attached patch to binutils and re-release.
It's surprising we didn't catch this when gcc-3.x/gcc2-2.95 were
getting their shakedown this summer. Oh well.
Also, Chris, you could take the opportunity of binutils-20021107-3 to
apply Egor's remaining patches... :-)
Oops. Previous patch still left a chunk of Egor's changes. New patch
replaces.
--Chuck
Index: pe-dll.c
===
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.45
diff -u -r1.45 pe-dll.c
--- pe-dll.c6 Nov 2002 19:36:20 - 1.45
+++ pe-dll.c9 Nov 2002 17:27:42 -
@@ -234,6 +235,8 @@
{ "libg2c.", 7 },
{ "libsupc++.", 10 },
{ "libobjc.", 8 },
+ { "libstdc++-2.", 12 },
+ { "libg2c-2.", 9 },
{ NULL, 0 }
};
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
On Sat, Nov 09, 2002 at 12:32:01PM -0500, Charles Wilson wrote:
>Charles Wilson wrote:
>
>
>>Nope. Chris should apply the attached patch to binutils and re-release.
>> It's surprising we didn't catch this when gcc-3.x/gcc2-2.95 were
>>getting their shakedown this summer. Oh well.
>>
>>Also, Chris, you could take the opportunity of binutils-20021107-3 to
>>apply Egor's remaining patches... :-)
>
>
>Oops. Previous patch still left a chunk of Egor's changes. New patch
>replaces.
How about submitting the patch to the binutils mailing list?
cgf
>Index: pe-dll.c
>===
>RCS file: /cvs/src/src/ld/pe-dll.c,v
>retrieving revision 1.45
>diff -u -r1.45 pe-dll.c
>--- pe-dll.c 6 Nov 2002 19:36:20 - 1.45
>+++ pe-dll.c 9 Nov 2002 17:27:42 -
>@@ -234,6 +235,8 @@
> { "libg2c.", 7 },
> { "libsupc++.", 10 },
> { "libobjc.", 8 },
>+ { "libstdc++-2.", 12 },
>+ { "libg2c-2.", 9 },
> { NULL, 0 }
> };
>
>
>--
>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
Christopher Faylor wrote: Nope. Chris should apply the attached patch to binutils and re-release. It's surprising we didn't catch this when gcc-3.x/gcc2-2.95 were getting their shakedown this summer. Oh well. Also, Chris, you could take the opportunity of binutils-20021107-3 to apply Egor's remaining patches... :-) Oops. Previous patch still left a chunk of Egor's changes. New patch replaces. How about submitting the patch to the binutils mailing list? I've no objections -- but the patch is a workaround for a cygwin-specific packaging decision (e.g. providing gcc-2.95.3 as "gcc-2" and renaming the runtime libs accordingly). Is that something that should go into the "real" binutils CVS, or should it be kept in the cygwin binutils package only? --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
Charles Wilson wrote:
Oops. Previous patch still left a chunk of Egor's changes. New
patch replaces.
How about submitting the patch to the binutils mailing list?
I've no objections -- but the patch is a workaround for a
cygwin-specific packaging decision (e.g. providing gcc-2.95.3 as "gcc-2"
and renaming the runtime libs accordingly).
Is that something that should go into the "real" binutils CVS, or should
it be kept in the cygwin binutils package only?
Another alternative -- slightly more general (don't include the "."
char, and take advantage of the fact that we only check the first N
characters of the name).
--Chuck
Index: pe-dll.c
===
RCS file: /cvs/src/src/ld/pe-dll.c,v
retrieving revision 1.45
diff -u -r1.45 pe-dll.c
--- pe-dll.c6 Nov 2002 19:36:20 - 1.45
+++ pe-dll.c9 Nov 2002 18:28:56 -
@@ -228,12 +229,12 @@
/* Do not specify library suffix explicitly, to allow for dllized versions. */
static autofilter_entry_type autofilter_liblist[] =
{
- { "libgcc.", 7 },
- { "libstdc++.", 10 },
- { "libmingw32.", 11 },
- { "libg2c.", 7 },
- { "libsupc++.", 10 },
- { "libobjc.", 8 },
+ { "libgcc", 6 },
+ { "libstdc++", 9 },
+ { "libmingw32", 10 },
+ { "libg2c", 6 },
+ { "libsupc++", 9 },
+ { "libobjc", 7 },
{ NULL, 0 }
};
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
On Sat, Nov 09, 2002 at 01:29:52PM -0500, Charles Wilson wrote:
>Charles Wilson wrote:
Oops. Previous patch still left a chunk of Egor's changes. New
patch replaces.
>>>
>>>How about submitting the patch to the binutils mailing list?
>>>
>>
>>
>>I've no objections -- but the patch is a workaround for a
>>cygwin-specific packaging decision (e.g. providing gcc-2.95.3 as "gcc-2"
>>and renaming the runtime libs accordingly).
>>
>>Is that something that should go into the "real" binutils CVS, or should
>>it be kept in the cygwin binutils package only?
>
>Another alternative -- slightly more general (don't include the "."
>char, and take advantage of the fact that we only check the first N
>characters of the name).
Shouldn't there be a few more entries in this list, like libmingwex,
libmingwthrd, libmsvcrt (maybe). I don't know if any of those libraries
have globals that could be erroneously exported but doesn't it pay to
be safe?
cgf
>Index: pe-dll.c
>===
>RCS file: /cvs/src/src/ld/pe-dll.c,v
>retrieving revision 1.45
>diff -u -r1.45 pe-dll.c
>--- pe-dll.c 6 Nov 2002 19:36:20 - 1.45
>+++ pe-dll.c 9 Nov 2002 18:28:56 -
>@@ -228,12 +229,12 @@
> /* Do not specify library suffix explicitly, to allow for dllized versions. */
> static autofilter_entry_type autofilter_liblist[] =
> {
>- { "libgcc.", 7 },
>- { "libstdc++.", 10 },
>- { "libmingw32.", 11 },
>- { "libg2c.", 7 },
>- { "libsupc++.", 10 },
>- { "libobjc.", 8 },
>+ { "libgcc", 6 },
>+ { "libstdc++", 9 },
>+ { "libmingw32", 10 },
>+ { "libg2c", 6 },
>+ { "libsupc++", 9 },
>+ { "libobjc", 7 },
> { NULL, 0 }
> };
>
>
>--
>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
How to read TAR diskette on Windows98/Me
To read a tar diskette on WindowsNT/XP/2000 the command "tar tvf /dev/fd0" works fine. It doesn't work on Windows98 or WindowsMe. What do you need to do to read a tar disk on those systems? I guess any program that would read a raw diskette and copy it to a file would do. Any suggestions on how to do this? How about Windows API code to read from a raw diskette? -- Paul B. McBride ([EMAIL PROTECTED]) http://homepages.rootsweb.com/~pmcbride/index.htm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
Christopher Faylor wrote: Shouldn't there be a few more entries in this list, like libmingwex, libmingwthrd, libmsvcrt (maybe). I don't know if any of those libraries have globals that could be erroneously exported but doesn't it pay to be safe? libmingwex -- maybe. I dunno -- that's for Danny and/or Earnie to say. You really only need library-name based protection for static libs; symbols in import libs are protected from re-export by symbol-exclude lists (_nm_*,__imp__*, etc). libmsvcrt, libmingwthrd -- no (because they are implibs). /usr/lib/mingw/libfrtbegin.a: x86 archive static /usr/lib/mingw/libglui.a: x86 archive static /usr/lib/mingw/libgluix.a: x86 archive static /usr/lib/mingw/libgmon.a: x86 archive static /usr/lib/mingw/libiberty.a: x86 archive static /usr/lib/mingw/libmingwex.a: x86 archive static /usr/lib/mingw/libmingw32.a: x86 archive stati /usr/lib/mingw/libg2c-2.a: x86 archive static /usr/lib/mingw/libg2c.a: x86 archive static /usr/lib/mingw/libgcc.a: x86 archive static /usr/lib/mingw/libobjc.a: x86 archive static /usr/lib/mingw/libstdc++-2.a: x86 archive static /usr/lib/mingw/libstdc++.a: x86 archive static /usr/lib/mingw/libsupc++.a: x86 archive static /usr/lib/mingw/libcoldname.a: x86 archive import /usr/lib/mingw/libcrtdll.a: x86 archive import /usr/lib/mingw/libmingwthrd.a: x86 archive import /usr/lib/mingw/libmoldname.a: x86 archive import /usr/lib/mingw/libmsvcrt.a: x86 archive import /usr/lib/mingw/libmsvcrt20.a: x86 archive import /usr/lib/mingw/libmsvcrt40.a: x86 archive import There may be other "system" and "compiler" libnames worth looking at in /usr/lib, like libautomode, libbinmode, libtextmode, libgcj, etc. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: no dice yet on .net server?
> > Hello, > > > > I've installed cygwin on a Microsoft .Net Server machine (yes, a > > "release candidate" build) just so that I can use bash, but it refuses > > to run. I've noticed the web page says 'The Cygwin DLL works with > > all non-beta, non "release candidate", ix86 versions of Windows > > since Windows 95, with the exception of Windows CE.' Does that > > mean cygwin deliberately checks the OS version and bails out if > > it's not among those expected, or simply that you haven't yet tested > > it on this OS and I've hit an incompatibility? > > > > I have cygwin running just fine on my Windows 2000 machines. > > It also works fine on .NET Server-ish (Windows XP SP1 switched to > server mode with NTSwitch), which is a shame because I was going > to try to debug it. I will try it on RC1 next week sometime and > have a look-see. Finally got round to trying Cygwin on .NET Enterprise Server RC1 and it works fine. Anyone who was having problems, are you still seeing these and can you give me any more details? Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: postgresql question
> > Me too. Sorry, I don't know why the regression test fails for you. Do you have done the test with the source of the recent cygwin release or are you using a newer release from www.postgresql.org ? (I'm using the first) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
On Sun, 2002-11-10 at 05:58, Charles Wilson wrote: > Christopher Faylor wrote: > > > > Shouldn't there be a few more entries in this list, like libmingwex, > > libmingwthrd, libmsvcrt (maybe). I don't know if any of those libraries > > have globals that could be erroneously exported but doesn't it pay to > > be safe? > > > libmingwex -- maybe. I dunno -- that's for Danny and/or Earnie to say. > You really only need library-name based protection for static libs; > symbols in import libs are protected from re-export by symbol-exclude > lists (_nm_*,__imp__*, etc). libmsvcrt, libmingwthrd -- no (because > they are implibs). A light just went on. We could use a "exclude system archive" flag - dont' export symbols originating from libraries in /usr/local/lib/* or /usr/lib/* ( and possibly the gcc lib dir as well - although I think that is a spec thing, as it's gcc's decision to have the library given a certain name). Whaddya think? Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: postgresql question
Ralf, On Sun, Nov 10, 2002 at 12:17:05AM +0100, Ralf Habacker wrote: > > Me too. Sorry, I don't know why the regression test fails for you. > > Do you have done the test with the source of the recent cygwin release > or are you using a newer release from www.postgresql.org ? > > (I'm using the first) I was using PostgreSQL CVS. Although I don't think there would be a difference (without inspecting the source code), maybe there was an issue in PostgreSQL 7.2.3 that was fixed in CVS (i.e., 7.3)? Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Seems a gcc update crept out without any announcement.
Seems a gcc update crept out without any announcement. Is there anything important/interesting in this new release? Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setup bug
Max Bowsher wrote: > Ummm... Why am I cc-ed personally on this? > Your replies were so helpful and authoritative that I thought that you were the Setup program maintainer! SAT. -RJC -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setup bug
On Sun, 2002-11-10 at 12:25, Robert J. Cristel wrote: > Max Bowsher wrote: > > Ummm... Why am I cc-ed personally on this? > > > Your replies were so helpful and authoritative that > I thought that you were the Setup program > maintainer! SAT. What does SAT mean? Also, for the record, I'm the setup maintainer :}. Max is a setup contributor, and well able to make authoritative statements about setup. BOTH of us (in fact, all maintainers and contributors of opensource packages I know of) prefer to contacted via the relevant mailing lists. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: binutils 20021107-2
Robert Collins wrote: libmingwex -- maybe. I dunno -- that's for Danny and/or Earnie to say. You really only need library-name based protection for static libs; symbols in import libs are protected from re-export by symbol-exclude lists (_nm_*,__imp__*, etc). libmsvcrt, libmingwthrd -- no (because they are implibs). A light just went on. We could use a "exclude system archive" flag - dont' export symbols originating from libraries in /usr/local/lib/* or /usr/lib/* ( and possibly the gcc lib dir as well - although I think that is a spec thing, as it's gcc's decision to have the library given a certain name). Whaddya think? I don't know if we have enough information in the auto_export() context. Here's what I found doing a simple link [ printing abfd->my->archive->filename when in auto_export() ]. Each line corresponds to a given symbol under consideration for auto-export (not shown) abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a abfd->my_arc->filename=/usr/lib/w32api/libkernel32.a abfd->my_arc->filename=/usr/lib/w32api/libkernel32.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a First, how does ld know about gcc's built in path /usr/lib/gcc-lib/i686-pc-cygwin/3.2/ ?. Second, we'd have to canonicalize /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../ to determine if it corresponded to the "system path" /usr/lib/ (which would be a nice trick on a cross-compiler setup) The good news is that almost everything in /usr/lib/w32api/ is an import lib, so those symbols are not re-exported anyway...exceptions: /usr/lib/w32api/libdxguid.a: x86 archive static /usr/lib/w32api/liblargeint.a: x86 archive static /usr/lib/w32api/libscrnsave.a: x86 archive static /usr/lib/w32api/libscrnsavw.a: x86 archive static So at least we needn't worry overmuch about ../w32api/.. But, I think it's overkill to define "system libs that should not be re-exported" as "anything in /usr/lib" or something similarly broad. Perhaps the "regular" gcc-supplied system libs (libgcc, libstdc++, libsupc++, etc) can be explicitly rejected by name from within the ld.exe code, but additional **platform** dependent static runtime libraries like libmingwex, etc should actually be controlled by the platform-specific gcc spec file, using --exclude-libs libmingwex.a,libcygwin.a,... - On the other hand, we're really arguing about a problem that hasn't bit anyone yet. By excluding the main (gcc) static runtime libs from re-export, and the main (platform) static runtime libs like libmingw32 libmingwex from re-export -- we pretty much cover all the important bases. Anything else is obviously a corner case, since it hasn't bit anyone yet -- and the fix is for that person to specifically exclude the static lib tha
Re: Setup bug
Robert Collins wrote: > > On Sun, 2002-11-10 at 12:25, Robert J. Cristel wrote: > > Max Bowsher wrote: > > > Ummm... Why am I cc-ed personally on this? > > > > > Your replies were so helpful and authoritative that > > I thought that you were the Setup program > > maintainer! SAT. > > What does SAT mean? > Sorry about that. > Max is a setup contributor, and well able to make authoritative > statements about setup. BOTH of us (in fact, all maintainers and > contributors of opensource packages I know of) prefer to contacted via > the relevant mailing lists. > ok. I'll drop the ccs. -RJC -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setup bug
On Sun, Nov 10, 2002 at 12:30:20PM +1100, Robert Collins wrote: >Max is a setup contributor, and well able to make authoritative >statements about setup. BOTH of us (in fact, all maintainers and >contributors of opensource packages I know of) prefer to contacted via >the relevant mailing lists. As is mentioned in http://cygwin.com/bugs.html . And, countless other places around the web... cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mbstate_t bug still around
This problem is fixed by the latest GCC release (gcc-3.2-2.tar.bz2) . Thanks, Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
On Sun, 2002-11-10 at 12:34, Charles Wilson wrote: > I don't know if we have enough information in the auto_export() context. > Here's what I found doing a simple link [ printing > abfd->my->archive->filename when in auto_export() ]. Each line > corresponds to a given symbol under consideration for auto-export (not > shown) > > abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/libgcc.a ok, so it is /usr/lib, and has no '..''s in the path. > abfd->my_arc->filename=/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../libcygwin.a And this one, as you say, would need normalising. > First, how does ld know about gcc's built in path > /usr/lib/gcc-lib/i686-pc-cygwin/3.2/ ?. That would be an optional issue. It is in /usr/lib though. So, I'd consider it a sub-path match. > Second, we'd have to > canonicalize /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../ to determine > if it corresponded to the "system path" /usr/lib/ (which would be a nice > trick on a cross-compiler setup) We could simply not match paths with '..' as an initial trial. > The good news is that almost everything in /usr/lib/w32api/ is an import > lib, so those symbols are not re-exported anyway...exceptions: > > /usr/lib/w32api/libdxguid.a: x86 archive static > /usr/lib/w32api/liblargeint.a: x86 archive static > /usr/lib/w32api/libscrnsave.a: x86 archive static > /usr/lib/w32api/libscrnsavw.a: x86 archive static > > So at least we needn't worry overmuch about ../w32api/.. > > But, I think it's overkill to define "system libs that should not be > re-exported" as "anything in /usr/lib" or something similarly broad. Why? *anything* in /usr/lib is able to be linked to from multiple packages. If one package creates a dll from there, then we will get this problem. We're currently *manually* excluding *how many* libs? fortran. gcc. stdc++. cygwin. And thats from memory. Do we want to hack ld when a test g++-3.3 is released? IMO No. > Perhaps the "regular" gcc-supplied system libs (libgcc, libstdc++, > libsupc++, etc) can be explicitly rejected by name from within the > ld.exe code, but additional **platform** dependent static runtime > libraries like libmingwex, etc should actually be controlled by the > platform-specific gcc spec file, using > > --exclude-libs libmingwex.a,libcygwin.a,... I think that nothing specific to gcc should be handled by ld. If gcc knows about file foo, be that mingw specific, or c++ specific, it should tell ld to do the right thing. This centralises the knowledge about the exceptions. > - > > On the other hand, we're really arguing about a problem that hasn't bit > anyone yet. By excluding the main (gcc) static runtime libs from > re-export, and the main (platform) static runtime libs like libmingw32 > libmingwex from re-export -- we pretty much cover all the important bases. True. My suspicion though is that as folk find .dll's easier to build, with the libtool dll support hitting mainstream as of(?1.4?) it will be more common to link against something. Let me give you another contrived example: I create a static lib foo (say readline for arguments sake). It gets installed into /usr/local/lib. Someone else makes a library bar depending on foo. This library is a .dll. It gets installed into /usr/local/lib. Every app that links against both foo and bar (and if bar is a libtool library, it will suck in foo for us) will get duplicate symbols. > Anything else is obviously a corner case, since it hasn't bit anyone yet > -- and the fix is for that person to specifically exclude the static lib > that "bit" them by using --exclude-libs. That is *a* fix. Why doesn't it bite folk on linux or BSD? Why should it bite anyone here when *we can make ld do the right thing*. We only want to export static archive symbols when a) it's a convenience library, b) we are creating a forwarding library for the archive. In a) the library won't be in /usr/lib unless you are building from a subdir of that (unlikely!). In b) the library *may* be in /usr/lib, so we can allow a --include-libs flag to override the heuristic (and I think we already have one, no?) > The problem here, is that because of our packaging of gcc-2, we're > missing the names of the (gcc) static runtime libs for that "package". > Plus, libmingwex is another (platform) static runtime lib that we're > missing -- but it was only recently added to the mingw "platform". The problem is that dll's are non intuitive, and our automagic support is incomplete :}. There's a refactoring smell, uhmm, 'Shotgun Surgery'. When we change the names of common system libraries, we have to change ld as well. That's plain wrong. > (I raised the issue of libtextmode & friends, but since the only > "re-exportable" symbol in them is _cygwin_premain0 which is already > excluded by autofilter_symbolprefixlist, there's no problem there.) > > I think the (newly revised) attached patch i
Re: Bash 2.05b.04 - shopt extglob not working?
Try
#!/bin/bash
shopt -s extglob
"Jari Aalto+list.cygwin" wrote:
>
> Isn't this supposed to work under Cygwin bash? I have "shopt extglob"
> enabled.
>
> Jari
>
> a=new;
>
> case $a in
> -d) echo 1 ;;
> @(add|new)) echo 2 ;;
> esac
>
> root@W2KPICASSO:~/config/shell/bash/complete$ bash -x ~/tmp/test.sh
> + bash -x ~/tmp/test.sh
> + a=new
> /cygdrive/e/home/jaalto/tmp/t3.sh: line 5: syntax error near unexpected token `('
> /cygdrive/e/home/jaalto/tmp/t3.sh: line 5: `@(add|new)) echo 2 ;;'
>
> root@W2KPICASSO:~/config/shell/bash/complete$ shopt
> + shopt
> cdable_vars off
> cdspell off
> checkhash off
> checkwinsizeoff
> cmdhist on
> dotglob off
> execfailoff
> expand_aliases on
> extglob on
> histreedit off
> histappend off
> histverify off
> hostcompleteon
> huponexit off
> interactive_commentson
> lithist off
> login_shell off
> mailwarnoff
> no_empty_cmd_completion off
> nocaseglob off
> nullgloboff
> progcompon
> promptvars on
> restricted_shelloff
> shift_verbose off
> sourcepath on
> xpg_echooff
>
> --
> http://tiny-tools.sourceforge.net/
> Swatch @time http://www.ryanthiessen.com/swatch/resources.htm
> Convert @time http://www.mir.com.my/iTime/itime.htm
>
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
--
Doug VanLeuven : 707-545-6945 (voice) 707-545-6945 (fax)
Programmer/Analyst, SCWA : [EMAIL PROTECTED]
Chief Engineer, USMM : [EMAIL PROTECTED]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: binutils 20021107-2
On Saturday 09 November 2002 15:45, Robert Collins wrote: > On Sun, 2002-11-10 at 05:58, Charles Wilson wrote: > > Christopher Faylor wrote: > > > Shouldn't there be a few more entries in this list, like libmingwex, > > > libmingwthrd, libmsvcrt (maybe). I don't know if any of those > > > libraries have globals that could be erroneously exported but doesn't > > > it pay to be safe? > > > > libmingwex -- maybe. I dunno -- that's for Danny and/or Earnie to say. > > You really only need library-name based protection for static libs; > > symbols in import libs are protected from re-export by symbol-exclude > > lists (_nm_*,__imp__*, etc). libmsvcrt, libmingwthrd -- no (because > > they are implibs). > > A light just went on. We could use a "exclude system archive" flag - > dont' export symbols originating from libraries in /usr/local/lib/* or > /usr/lib/* ( and possibly the gcc lib dir as well - although I think > that is a spec thing, as it's gcc's decision to have the library given a > certain name). > g77 now tries to link against mingw runtime, as gcc -pg did previously. Even though I had un-installed mingw, the new installation re-installed it. -- Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin 1.3.15-1: setup 2.249.2.5 stack fault when installing on win98 SE
I posted this a few days ago. The problem still exists and I actually can't find the post when I search the mailing list so I think somehow it may have gotten lost in the ether. I am trying to install Cygwin 1.3.15-1 with PCR-tools on Win98 SE using setup.exe 2.249.2.5 off http://cygwin.com. I have tried both installing from the internet and installing from local directory. One of two problems occurs, depending on which method I use. When installing from the internet: When the download has progressed to 99% and it is about to install the installation reports and error and stops. When installing from local directory: I am able to get through the package selection dialogue. It progresses to the installation dialogue and then reports a stack fault in KERNEL32.DLL. A directory structure c:\cygwin\ is created with several folder and four files. The files that are installed are: C:\cygwin\var\run\utmp - it is blank when viewed with notepad C:\cygwin\etc\setup\timestamp - when viewed with notepad "1036305608" C:\cygwin\etc\setup\ash.lst.gz - When viewed with winzip it has no contents C:\cygwin\etc\setup\last-cahe - When viewed with notepad simply says "C:\install" Prior to the stack fault the setup window says: Installing ash-200220731-1 /bin/sh.exe The status bars show no progression. The stack fault details show: SETUP caused a stack fault in module KERNEL32.DLL at 017f:bff7429f. Registers: EAX=817f32e4 CS=017f EIP=bff7429f EFLGS=0283 EBX=01312054 SS=0187 ESP=01312008 EBP=01312038 ECX=d55b4e10 DS=0187 ESI=01312087 FS=651f EDX=bffc9490 ES=0187 EDI=001d GS= Bytes at CS:EIP: eb 95 8b 54 24 04 50 e8 04 00 00 00 58 c2 04 00 Stack dump: bff741f7 bffc9490 bff7cdf9 bffc9490 0001 01312087 013121b4 01312030 01312089 0001 bffc9002 01312058 bff7ceed 01312087 0104 I have searched the mailing list and google, and read the faq. I have tried the following things: (1) Turning off Norton Anti Virus (2) Installing using this file setup-2.259.2.4.exe from http://www.cygwin.com/setup-snapshots/ (3) Searching for an older version of setup.exe (4) Visiting microsoft.com to learn more about stack faults in KERNEL32.DLL (nothing useful there) (5) Moving the downloaded files to a folder that does not contain escape characters in its name (6) Trying different server options for the download (7) Avoiding changing package options (after reading a post suggesting that a bug cuases setup to crash when options are changed at the package picker dialogue for the first installation of cygwin. Nothing I have tried has worked. Any help would be much appreciated. Best regards, Xenicus Starr -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Calling an Cygwin API function within Delphi
How could I call an cygwin API function within delphi? Every attempt to do this crashes my app. Benjamin Kalytta -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
