* regex.c not found, but it clearly exists @ 2007-12-14 7:05 NightStrike 2007-12-14 7:18 ` Brian Dessent 2007-12-14 7:19 ` Rick Mann 0 siblings, 2 replies; 21+ messages in thread From: NightStrike @ 2007-12-14 7:05 UTC (permalink / raw) To: Binutils When compiling binutils in a cygwin shell using the mingw binary release of gcc, I see the following confusing thing: NightStrike@coolermaster1 /tmp/b6/bu/libiberty $ make if [ x"" != x ]; then \ i686-pc-mingw32-gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I/tmp/build/binutils/src/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic /tmp/build/binutils/src/libiberty/regex.c -o pic/regex.o; \ else true; fi i686-pc-mingw32-gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I/tmp/build/binutils/src/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic /tmp/build/binutils/src/libiberty/regex.c -o regex.o gcc.exe: /tmp/build/binutils/src/libiberty/regex.c: No such file or directory gcc.exe: no input files make: *** [regex.o] Error 1 NightStrike@coolermaster1 /tmp/b6/bu/libiberty $ ls -la /tmp/build/binutils/src/libiberty/regex.c -rw-r--r-- 1 NightStrike None 253K Jul 22 2005 /tmp/build/binutils/src/libiberty/regex.c As you can see, the file does exist and is nonzero. It is readable by user, group, and world. Why would gcc say it does not exist? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2007-12-14 7:05 regex.c not found, but it clearly exists NightStrike @ 2007-12-14 7:18 ` Brian Dessent 2007-12-14 9:42 ` Andrew STUBBS 2007-12-14 7:19 ` Rick Mann 1 sibling, 1 reply; 21+ messages in thread From: Brian Dessent @ 2007-12-14 7:18 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: > As you can see, the file does exist and is nonzero. It is readable by > user, group, and world. Why would gcc say it does not exist? You're feeding a POSIX path to a MinGW application. MinGW applications have no path translation ability and can only accept Win32 paths. So no, the file does not exist in the eyes of i686-pc-mingw32-gcc because it has no idea what /tmp is supposed to mean. But 'ls' is a Cygwin app and knows what /tmp is, so of course that works. You need to use MSYS if you want this to work, because MSYS does path translation of command line arguments when invoking MinGW apps. Cygwin does not because Cygwin is not intended to work with apps that don't understand POSIX paths. This has nothing to do with binutils, so I suggest you follow up on the MinGW list. Brian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2007-12-14 7:18 ` Brian Dessent @ 2007-12-14 9:42 ` Andrew STUBBS 2007-12-17 23:22 ` NightStrike 0 siblings, 1 reply; 21+ messages in thread From: Andrew STUBBS @ 2007-12-14 9:42 UTC (permalink / raw) Cc: NightStrike, Binutils Brian Dessent wrote: > NightStrike wrote: > >> As you can see, the file does exist and is nonzero. It is readable by >> user, group, and world. Why would gcc say it does not exist? > > You're feeding a POSIX path to a MinGW application. MinGW applications > have no path translation ability and can only accept Win32 paths. So > no, the file does not exist in the eyes of i686-pc-mingw32-gcc because > it has no idea what /tmp is supposed to mean. But 'ls' is a Cygwin app > and knows what /tmp is, so of course that works. > > You need to use MSYS if you want this to work, because MSYS does path > translation of command line arguments when invoking MinGW apps. Cygwin > does not because Cygwin is not intended to work with apps that don't > understand POSIX paths. Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. That's a Cygwin program so it understands the POSIX paths, but it produced MinGW programs (which don't). Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2007-12-14 9:42 ` Andrew STUBBS @ 2007-12-17 23:22 ` NightStrike 2008-01-02 12:48 ` Andrew STUBBS 0 siblings, 1 reply; 21+ messages in thread From: NightStrike @ 2007-12-17 23:22 UTC (permalink / raw) To: Andrew STUBBS; +Cc: Binutils On 12/14/07, Andrew STUBBS <andrew.stubbs@st.com> wrote: > Brian Dessent wrote: > > NightStrike wrote: > > > >> As you can see, the file does exist and is nonzero. It is readable by > >> user, group, and world. Why would gcc say it does not exist? > > > > You're feeding a POSIX path to a MinGW application. MinGW applications > > have no path translation ability and can only accept Win32 paths. So > > no, the file does not exist in the eyes of i686-pc-mingw32-gcc because > > it has no idea what /tmp is supposed to mean. But 'ls' is a Cygwin app > > and knows what /tmp is, so of course that works. > > > > You need to use MSYS if you want this to work, because MSYS does path > > translation of command line arguments when invoking MinGW apps. Cygwin > > does not because Cygwin is not intended to work with apps that don't > > understand POSIX paths. > > Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. > > That's a Cygwin program so it understands the POSIX paths, but it > produced MinGW programs (which don't). Are programs compiled in this fashion identical to programs that are compiled with the actual i686-pc-mingw-gcc program? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2007-12-17 23:22 ` NightStrike @ 2008-01-02 12:48 ` Andrew STUBBS 2008-01-02 16:19 ` Andrew STUBBS ` (8 more replies) 0 siblings, 9 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-02 12:48 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: >> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >> >> That's a Cygwin program so it understands the POSIX paths, but it >> produced MinGW programs (which don't). > > Are programs compiled in this fashion identical to programs that are > compiled with the actual i686-pc-mingw-gcc program? Since nobody more qualified has responded ... I don't know if they are perfectly identical, but they certainly have the same general properties. That is, in order to build a UNIX program you have to apply the exact same patches as you would for the MinGW compiler. Note that you must have installed the right Cygwin package for it to work - it uses a different set of libraries in -mno-cygwin mode. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 12:48 ` Andrew STUBBS @ 2008-01-02 16:19 ` Andrew STUBBS 2008-01-02 16:50 ` Andrew STUBBS ` (7 subsequent siblings) 8 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-02 16:19 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: >> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >> >> That's a Cygwin program so it understands the POSIX paths, but it >> produced MinGW programs (which don't). > > Are programs compiled in this fashion identical to programs that are > compiled with the actual i686-pc-mingw-gcc program? Since nobody more qualified has responded ... I don't know if they are perfectly identical, but they certainly have the same general properties. That is, in order to build a UNIX program you have to apply the exact same patches as you would for the MinGW compiler. Note that you must have installed the right Cygwin package for it to work - it uses a different set of libraries in -mno-cygwin mode. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 12:48 ` Andrew STUBBS 2008-01-02 16:19 ` Andrew STUBBS @ 2008-01-02 16:50 ` Andrew STUBBS 2008-01-02 19:16 ` Andrew STUBBS ` (6 subsequent siblings) 8 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-02 16:50 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: >> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >> >> That's a Cygwin program so it understands the POSIX paths, but it >> produced MinGW programs (which don't). > > Are programs compiled in this fashion identical to programs that are > compiled with the actual i686-pc-mingw-gcc program? Since nobody more qualified has responded ... I don't know if they are perfectly identical, but they certainly have the same general properties. That is, in order to build a UNIX program you have to apply the exact same patches as you would for the MinGW compiler. Note that you must have installed the right Cygwin package for it to work - it uses a different set of libraries in -mno-cygwin mode. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 12:48 ` Andrew STUBBS 2008-01-02 16:19 ` Andrew STUBBS 2008-01-02 16:50 ` Andrew STUBBS @ 2008-01-02 19:16 ` Andrew STUBBS 2008-01-02 20:03 ` Andrew STUBBS ` (5 subsequent siblings) 8 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-02 19:16 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: >> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >> >> That's a Cygwin program so it understands the POSIX paths, but it >> produced MinGW programs (which don't). > > Are programs compiled in this fashion identical to programs that are > compiled with the actual i686-pc-mingw-gcc program? Since nobody more qualified has responded ... I don't know if they are perfectly identical, but they certainly have the same general properties. That is, in order to build a UNIX program you have to apply the exact same patches as you would for the MinGW compiler. Note that you must have installed the right Cygwin package for it to work - it uses a different set of libraries in -mno-cygwin mode. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 12:48 ` Andrew STUBBS ` (2 preceding siblings ...) 2008-01-02 19:16 ` Andrew STUBBS @ 2008-01-02 20:03 ` Andrew STUBBS 2008-01-02 20:59 ` Dave Korn ` (4 subsequent siblings) 8 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-02 20:03 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: >> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >> >> That's a Cygwin program so it understands the POSIX paths, but it >> produced MinGW programs (which don't). > > Are programs compiled in this fashion identical to programs that are > compiled with the actual i686-pc-mingw-gcc program? Since nobody more qualified has responded ... I don't know if they are perfectly identical, but they certainly have the same general properties. That is, in order to build a UNIX program you have to apply the exact same patches as you would for the MinGW compiler. Note that you must have installed the right Cygwin package for it to work - it uses a different set of libraries in -mno-cygwin mode. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: regex.c not found, but it clearly exists 2008-01-02 12:48 ` Andrew STUBBS ` (3 preceding siblings ...) 2008-01-02 20:03 ` Andrew STUBBS @ 2008-01-02 20:59 ` Dave Korn 2008-01-02 21:44 ` Andrew STUBBS 2008-01-02 23:56 ` Andrew STUBBS ` (3 subsequent siblings) 8 siblings, 1 reply; 21+ messages in thread From: Dave Korn @ 2008-01-02 20:59 UTC (permalink / raw) To: 'Andrew STUBBS', 'NightStrike'; +Cc: 'Binutils' On 02 January 2008 12:42, Andrew STUBBS wrote: > NightStrike wrote: >>> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >>> >>> That's a Cygwin program so it understands the POSIX paths, but it >>> produced MinGW programs (which don't). >> >> Are programs compiled in this fashion identical to programs that are >> compiled with the actual i686-pc-mingw-gcc program? > > Since nobody more qualified has responded ... > > I don't know if they are perfectly identical, but they certainly have > the same general properties. That is, in order to build a UNIX program > you have to apply the exact same patches as you would for the MinGW > compiler. This is basically it, but there are some problems. The -mno-cygwin flag and the cross-compile mode of the cygming-targeted compiler are somewhat kludgey. The major purpose for which they are packaged is so that you can rebuild the cygwin dll itself from within the cygwin environment. It's not really intended for general cross-development, and although it'll just about do, there is a problem: it doesn't correctly switch over /all/ the default search paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still searches the cygwin compiler-specific include dir /usr/lib/gcc/i686-pc-cygwin/3.4.4/include when it should be looking in: /usr/lib/gcc/i686-pc-mingw32/3.4.4/include I don't know - and couldn't say for sure without doing a thorough audit - how serious this could be, but from running a very quick diff over it, I can see that it might in particular affect C++. (It could easily break passing std::strings across DLL boundaries, which cygwin has some custom mods to the c++ stl header files relating to). > Note that you must have installed the right Cygwin package for it to > work - it uses a different set of libraries in -mno-cygwin mode. Yes, the packages required for -mno-cygwin are w32api and mingw-runtime IIRC. cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 20:59 ` Dave Korn @ 2008-01-02 21:44 ` Andrew STUBBS 2008-01-02 23:56 ` Andrew STUBBS ` (4 more replies) 0 siblings, 5 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-02 21:44 UTC (permalink / raw) To: Dave Korn; +Cc: 'NightStrike', 'Binutils' Dave Korn wrote: > This is basically it, but there are some problems. The -mno-cygwin flag and > the cross-compile mode of the cygming-targeted compiler are somewhat kludgey. > The major purpose for which they are packaged is so that you can rebuild the > cygwin dll itself from within the cygwin environment. It's not really > intended for general cross-development, and although it'll just about do, > there is a problem: it doesn't correctly switch over /all/ the default search > paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc > -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still > searches the cygwin compiler-specific include dir > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include > > when it should be looking in: > > /usr/lib/gcc/i686-pc-mingw32/3.4.4/include > > I don't know - and couldn't say for sure without doing a thorough audit - > how serious this could be, but from running a very quick diff over it, I can > see that it might in particular affect C++. (It could easily break passing > std::strings across DLL boundaries, which cygwin has some custom mods to the > c++ stl header files relating to). We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb and a few other bits and pieces. I've never had any trouble with search paths that I couldn't blame on the build system, although no doubt there are some pit-falls to be had. Obviously there are a number of patches required to build all those utilities on windows. We also have a few patches to make the tools understand /cygdrive paths in a limited way - it won't build the target libraries without. We used to target Cygwin, rather than Windows, but that meant that all our customers also had to use Cygwin, and there were version mismatch problems to overcome. Andrew P.S. Sorry about the multiple posts - I've received a notification from the mailserver saying that it's having trouble sending the message, but there doesn't seem to be any way to tell it not to bother. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 21:44 ` Andrew STUBBS @ 2008-01-02 23:56 ` Andrew STUBBS 2008-01-03 2:15 ` Andrew STUBBS ` (3 subsequent siblings) 4 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-02 23:56 UTC (permalink / raw) To: Dave Korn; +Cc: 'NightStrike', 'Binutils' Dave Korn wrote: > This is basically it, but there are some problems. The -mno-cygwin flag and > the cross-compile mode of the cygming-targeted compiler are somewhat kludgey. > The major purpose for which they are packaged is so that you can rebuild the > cygwin dll itself from within the cygwin environment. It's not really > intended for general cross-development, and although it'll just about do, > there is a problem: it doesn't correctly switch over /all/ the default search > paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc > -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still > searches the cygwin compiler-specific include dir > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include > > when it should be looking in: > > /usr/lib/gcc/i686-pc-mingw32/3.4.4/include > > I don't know - and couldn't say for sure without doing a thorough audit - > how serious this could be, but from running a very quick diff over it, I can > see that it might in particular affect C++. (It could easily break passing > std::strings across DLL boundaries, which cygwin has some custom mods to the > c++ stl header files relating to). We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb and a few other bits and pieces. I've never had any trouble with search paths that I couldn't blame on the build system, although no doubt there are some pit-falls to be had. Obviously there are a number of patches required to build all those utilities on windows. We also have a few patches to make the tools understand /cygdrive paths in a limited way - it won't build the target libraries without. We used to target Cygwin, rather than Windows, but that meant that all our customers also had to use Cygwin, and there were version mismatch problems to overcome. Andrew P.S. Sorry about the multiple posts - I've received a notification from the mailserver saying that it's having trouble sending the message, but there doesn't seem to be any way to tell it not to bother. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 21:44 ` Andrew STUBBS 2008-01-02 23:56 ` Andrew STUBBS @ 2008-01-03 2:15 ` Andrew STUBBS 2008-01-03 5:26 ` Andrew STUBBS ` (2 subsequent siblings) 4 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-03 2:15 UTC (permalink / raw) To: Dave Korn; +Cc: 'NightStrike', 'Binutils' Dave Korn wrote: > This is basically it, but there are some problems. The -mno-cygwin flag and > the cross-compile mode of the cygming-targeted compiler are somewhat kludgey. > The major purpose for which they are packaged is so that you can rebuild the > cygwin dll itself from within the cygwin environment. It's not really > intended for general cross-development, and although it'll just about do, > there is a problem: it doesn't correctly switch over /all/ the default search > paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc > -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still > searches the cygwin compiler-specific include dir > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include > > when it should be looking in: > > /usr/lib/gcc/i686-pc-mingw32/3.4.4/include > > I don't know - and couldn't say for sure without doing a thorough audit - > how serious this could be, but from running a very quick diff over it, I can > see that it might in particular affect C++. (It could easily break passing > std::strings across DLL boundaries, which cygwin has some custom mods to the > c++ stl header files relating to). We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb and a few other bits and pieces. I've never had any trouble with search paths that I couldn't blame on the build system, although no doubt there are some pit-falls to be had. Obviously there are a number of patches required to build all those utilities on windows. We also have a few patches to make the tools understand /cygdrive paths in a limited way - it won't build the target libraries without. We used to target Cygwin, rather than Windows, but that meant that all our customers also had to use Cygwin, and there were version mismatch problems to overcome. Andrew P.S. Sorry about the multiple posts - I've received a notification from the mailserver saying that it's having trouble sending the message, but there doesn't seem to be any way to tell it not to bother. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 21:44 ` Andrew STUBBS 2008-01-02 23:56 ` Andrew STUBBS 2008-01-03 2:15 ` Andrew STUBBS @ 2008-01-03 5:26 ` Andrew STUBBS 2008-01-03 15:29 ` Andrew STUBBS 2008-01-03 16:06 ` Andrew STUBBS 4 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-03 5:26 UTC (permalink / raw) To: Dave Korn; +Cc: 'NightStrike', 'Binutils' Dave Korn wrote: > This is basically it, but there are some problems. The -mno-cygwin flag and > the cross-compile mode of the cygming-targeted compiler are somewhat kludgey. > The major purpose for which they are packaged is so that you can rebuild the > cygwin dll itself from within the cygwin environment. It's not really > intended for general cross-development, and although it'll just about do, > there is a problem: it doesn't correctly switch over /all/ the default search > paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc > -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still > searches the cygwin compiler-specific include dir > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include > > when it should be looking in: > > /usr/lib/gcc/i686-pc-mingw32/3.4.4/include > > I don't know - and couldn't say for sure without doing a thorough audit - > how serious this could be, but from running a very quick diff over it, I can > see that it might in particular affect C++. (It could easily break passing > std::strings across DLL boundaries, which cygwin has some custom mods to the > c++ stl header files relating to). We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb and a few other bits and pieces. I've never had any trouble with search paths that I couldn't blame on the build system, although no doubt there are some pit-falls to be had. Obviously there are a number of patches required to build all those utilities on windows. We also have a few patches to make the tools understand /cygdrive paths in a limited way - it won't build the target libraries without. We used to target Cygwin, rather than Windows, but that meant that all our customers also had to use Cygwin, and there were version mismatch problems to overcome. Andrew P.S. Sorry about the multiple posts - I've received a notification from the mailserver saying that it's having trouble sending the message, but there doesn't seem to be any way to tell it not to bother. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 21:44 ` Andrew STUBBS ` (2 preceding siblings ...) 2008-01-03 5:26 ` Andrew STUBBS @ 2008-01-03 15:29 ` Andrew STUBBS 2008-01-03 16:06 ` Andrew STUBBS 4 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-03 15:29 UTC (permalink / raw) To: Dave Korn; +Cc: 'NightStrike', 'Binutils' Dave Korn wrote: > This is basically it, but there are some problems. The -mno-cygwin flag and > the cross-compile mode of the cygming-targeted compiler are somewhat kludgey. > The major purpose for which they are packaged is so that you can rebuild the > cygwin dll itself from within the cygwin environment. It's not really > intended for general cross-development, and although it'll just about do, > there is a problem: it doesn't correctly switch over /all/ the default search > paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc > -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still > searches the cygwin compiler-specific include dir > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include > > when it should be looking in: > > /usr/lib/gcc/i686-pc-mingw32/3.4.4/include > > I don't know - and couldn't say for sure without doing a thorough audit - > how serious this could be, but from running a very quick diff over it, I can > see that it might in particular affect C++. (It could easily break passing > std::strings across DLL boundaries, which cygwin has some custom mods to the > c++ stl header files relating to). We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb and a few other bits and pieces. I've never had any trouble with search paths that I couldn't blame on the build system, although no doubt there are some pit-falls to be had. Obviously there are a number of patches required to build all those utilities on windows. We also have a few patches to make the tools understand /cygdrive paths in a limited way - it won't build the target libraries without. We used to target Cygwin, rather than Windows, but that meant that all our customers also had to use Cygwin, and there were version mismatch problems to overcome. Andrew P.S. Sorry about the multiple posts - I've received a notification from the mailserver saying that it's having trouble sending the message, but there doesn't seem to be any way to tell it not to bother. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 21:44 ` Andrew STUBBS ` (3 preceding siblings ...) 2008-01-03 15:29 ` Andrew STUBBS @ 2008-01-03 16:06 ` Andrew STUBBS 4 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-03 16:06 UTC (permalink / raw) To: Dave Korn; +Cc: 'NightStrike', 'Binutils' Dave Korn wrote: > This is basically it, but there are some problems. The -mno-cygwin flag and > the cross-compile mode of the cygming-targeted compiler are somewhat kludgey. > The major purpose for which they are packaged is so that you can rebuild the > cygwin dll itself from within the cygwin environment. It's not really > intended for general cross-development, and although it'll just about do, > there is a problem: it doesn't correctly switch over /all/ the default search > paths; if you compare the output of "gcc -v -E -xc - < /dev/null" and "gcc > -mno-cygwin -v -E -xc - < /dev/null", you'll see that gcc -mno-cygwin still > searches the cygwin compiler-specific include dir > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/include > > when it should be looking in: > > /usr/lib/gcc/i686-pc-mingw32/3.4.4/include > > I don't know - and couldn't say for sure without doing a thorough audit - > how serious this could be, but from running a very quick diff over it, I can > see that it might in particular affect C++. (It could easily break passing > std::strings across DLL boundaries, which cygwin has some custom mods to the > c++ stl header files relating to). We use it to build a complete cross-toolset - binutils, gcc, newlib, gdb and a few other bits and pieces. I've never had any trouble with search paths that I couldn't blame on the build system, although no doubt there are some pit-falls to be had. Obviously there are a number of patches required to build all those utilities on windows. We also have a few patches to make the tools understand /cygdrive paths in a limited way - it won't build the target libraries without. We used to target Cygwin, rather than Windows, but that meant that all our customers also had to use Cygwin, and there were version mismatch problems to overcome. Andrew P.S. Sorry about the multiple posts - I've received a notification from the mailserver saying that it's having trouble sending the message, but there doesn't seem to be any way to tell it not to bother. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 12:48 ` Andrew STUBBS ` (4 preceding siblings ...) 2008-01-02 20:59 ` Dave Korn @ 2008-01-02 23:56 ` Andrew STUBBS 2008-01-03 12:57 ` Andrew STUBBS ` (2 subsequent siblings) 8 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-02 23:56 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: >> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >> >> That's a Cygwin program so it understands the POSIX paths, but it >> produced MinGW programs (which don't). > > Are programs compiled in this fashion identical to programs that are > compiled with the actual i686-pc-mingw-gcc program? Since nobody more qualified has responded ... I don't know if they are perfectly identical, but they certainly have the same general properties. That is, in order to build a UNIX program you have to apply the exact same patches as you would for the MinGW compiler. Note that you must have installed the right Cygwin package for it to work - it uses a different set of libraries in -mno-cygwin mode. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 12:48 ` Andrew STUBBS ` (5 preceding siblings ...) 2008-01-02 23:56 ` Andrew STUBBS @ 2008-01-03 12:57 ` Andrew STUBBS 2008-01-03 15:44 ` Andrew STUBBS 2008-01-03 16:17 ` Andrew STUBBS 8 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-03 12:57 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: >> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >> >> That's a Cygwin program so it understands the POSIX paths, but it >> produced MinGW programs (which don't). > > Are programs compiled in this fashion identical to programs that are > compiled with the actual i686-pc-mingw-gcc program? Since nobody more qualified has responded ... I don't know if they are perfectly identical, but they certainly have the same general properties. That is, in order to build a UNIX program you have to apply the exact same patches as you would for the MinGW compiler. Note that you must have installed the right Cygwin package for it to work - it uses a different set of libraries in -mno-cygwin mode. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 12:48 ` Andrew STUBBS ` (6 preceding siblings ...) 2008-01-03 12:57 ` Andrew STUBBS @ 2008-01-03 15:44 ` Andrew STUBBS 2008-01-03 16:17 ` Andrew STUBBS 8 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-03 15:44 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: >> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >> >> That's a Cygwin program so it understands the POSIX paths, but it >> produced MinGW programs (which don't). > > Are programs compiled in this fashion identical to programs that are > compiled with the actual i686-pc-mingw-gcc program? Since nobody more qualified has responded ... I don't know if they are perfectly identical, but they certainly have the same general properties. That is, in order to build a UNIX program you have to apply the exact same patches as you would for the MinGW compiler. Note that you must have installed the right Cygwin package for it to work - it uses a different set of libraries in -mno-cygwin mode. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2008-01-02 12:48 ` Andrew STUBBS ` (7 preceding siblings ...) 2008-01-03 15:44 ` Andrew STUBBS @ 2008-01-03 16:17 ` Andrew STUBBS 8 siblings, 0 replies; 21+ messages in thread From: Andrew STUBBS @ 2008-01-03 16:17 UTC (permalink / raw) To: NightStrike; +Cc: Binutils NightStrike wrote: >> Or you could try "gcc -mno-cygwin" where gcc is the standard Cygwin gcc. >> >> That's a Cygwin program so it understands the POSIX paths, but it >> produced MinGW programs (which don't). > > Are programs compiled in this fashion identical to programs that are > compiled with the actual i686-pc-mingw-gcc program? Since nobody more qualified has responded ... I don't know if they are perfectly identical, but they certainly have the same general properties. That is, in order to build a UNIX program you have to apply the exact same patches as you would for the MinGW compiler. Note that you must have installed the right Cygwin package for it to work - it uses a different set of libraries in -mno-cygwin mode. Andrew ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: regex.c not found, but it clearly exists 2007-12-14 7:05 regex.c not found, but it clearly exists NightStrike 2007-12-14 7:18 ` Brian Dessent @ 2007-12-14 7:19 ` Rick Mann 1 sibling, 0 replies; 21+ messages in thread From: Rick Mann @ 2007-12-14 7:19 UTC (permalink / raw) To: NightStrike; +Cc: Binutils On Dec 13, 2007, at 11:05 PM, NightStrike wrote: > When compiling binutils in a cygwin shell using the mingw binary > release of gcc, I see the following confusing thing: Let me ask: is regex.c a symlink to the real regex.c? If so, you probably created the symlink with Cygwin's ln, but mingw doesn't use the Cygwin I/O library, and so can't read the symlink correctly. I just learned this myself. I ended up building with Cygwin's GCC. -- Rick ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2008-01-02 21:05 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-12-14 7:05 regex.c not found, but it clearly exists NightStrike 2007-12-14 7:18 ` Brian Dessent 2007-12-14 9:42 ` Andrew STUBBS 2007-12-17 23:22 ` NightStrike 2008-01-02 12:48 ` Andrew STUBBS 2008-01-02 16:19 ` Andrew STUBBS 2008-01-02 16:50 ` Andrew STUBBS 2008-01-02 19:16 ` Andrew STUBBS 2008-01-02 20:03 ` Andrew STUBBS 2008-01-02 20:59 ` Dave Korn 2008-01-02 21:44 ` Andrew STUBBS 2008-01-02 23:56 ` Andrew STUBBS 2008-01-03 2:15 ` Andrew STUBBS 2008-01-03 5:26 ` Andrew STUBBS 2008-01-03 15:29 ` Andrew STUBBS 2008-01-03 16:06 ` Andrew STUBBS 2008-01-02 23:56 ` Andrew STUBBS 2008-01-03 12:57 ` Andrew STUBBS 2008-01-03 15:44 ` Andrew STUBBS 2008-01-03 16:17 ` Andrew STUBBS 2007-12-14 7:19 ` Rick Mann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).