From: Earnie B. <ear...@ya...> - 2000-11-07 21:48:24
|
--- Paul Sokolovsky <pa...@is...> wrote: > Hello Earnie, > Hi Paul, > > EB> Would it make since to add this switch to the GCC default specs file? > > That's what I think about too. Cygwin compatibility is issue to > think about however. Well, and generally - gcc compatibility issue at > all. > I'm of the opinion that MinGW support from Cygwin should be a full canadian cross. So, if I have Cygwin then I should have to use `configure --host=mingw32' in order to build it and the cross generated tools would handle the build. I would really like to eliminate the -mno-cygwin hack for MinGW support. BTW, I've held this opinion for several years. However, Chris is currently working on full separation of headers and libraries. There will be a /usr/include/w32api and a /usr/lib/mingw to house the non-cygwin headers and libraries. The default Cygwin GCC specs will handle the addition of the appropriate subdirectories for include files and libraries based on the presence of the -mno-cygwin flag. Cheers, ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ |
From: Earnie B. <ear...@ya...> - 2000-11-07 23:48:09
|
--- Paul Sokolovsky <pa...@is...> wrote: > Hello Earnie, > > Earnie Boyd <ear...@ya...> wrote: > > >> EB> Would it make since to add this switch to the GCC default specs file? > >> > >> That's what I think about too. Cygwin compatibility is issue to > >> think about however. Well, and generally - gcc compatibility issue at > >> all. > >> > > EB> I'm of the opinion that MinGW support from Cygwin should be a full > canadian > EB> cross. So, if I have Cygwin then I should have to use `configure > EB> --host=mingw32' in order to build it and the cross generated tools would > handle > EB> the build. I would really like to eliminate the -mno-cygwin hack for > MinGW > EB> support. BTW, I've held this opinion for several years. > > That's good news, but I meant something else. Having different gcc > settings between mingw and cygwin will complicate binary portability > between them - and I for sure yet would like to think what is more > important - compatibility with foreign compiler or compatibility among > win32 versions of gcc. > The -fnative-struct could be added to Cygwin's -mno-cygwin by default as well. We shouldn't care about Cygwin specific libraries. Cheers, ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ |
From: Earnie B. <ear...@ya...> - 2000-11-08 19:30:09
|
--- Tor Lillqvist <tm...@ik...> wrote: > Paul Sokolovsky writes: > > That's good news, but I meant something else. Having different gcc > > settings between mingw and cygwin will complicate binary portability > > between them - and I for sure yet would like to think what is more > > important - compatibility with foreign compiler or compatibility among > > win32 versions of gcc. > > But isn't it so that you shouldn't be mixing code using different C > runtime (msvcrt vs. cygwin) in an app and the DLLs it uses anyway? > Yes, you cannot mix msvcrt and cygwin runtimes in an executable. Cygwin is too dependant on Newlib's reentrancy coding to mix the two runtimes. And for MinGW, "compatibility amount win32 versions of gcc" sounds like it's a must. Although, I'm not sure of what "complicate binary portability" problems would exist. Cheers, ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ |
From: Paul G. <pga...@te...> - 2000-11-08 23:59:25
|
On 8 Nov 2000, at 11:29, the Illustrious Earnie Boyd wrote: > --- Tor Lillqvist <tm...@ik...> wrote: > > Paul Sokolovsky writes: > > > That's good news, but I meant something else. Having > > > different gcc settings between mingw and cygwin will > > > complicate binary portability between them - and I for sure > > > yet would like to think what is more important - > > > compatibility with foreign compiler or compatibility among > > > win32 versions of gcc. > > > > But isn't it so that you shouldn't be mixing code using > > different C runtime (msvcrt vs. cygwin) in an app and the DLLs > > it uses anyway? > > > > Yes, you cannot mix msvcrt and cygwin runtimes in an executable. > Cygwin is too dependant on Newlib's reentrancy coding to mix the > two runtimes. Thanks for clarifying that, Earnie. > And for MinGW, "compatibility amount win32 > versions of gcc" sounds like it's a must. I agree. > Although, I'm not sure > of what "complicate binary portability" problems would exist. My hunch is that it would be a major mess...not something I care to think about...;-) Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Paul G. <pga...@te...> - 2000-11-09 00:00:10
|
On 8 Nov 2000, at 11:29, the Illustrious Earnie Boyd wrote: > --- Tor Lillqvist <tm...@ik...> wrote: > > Paul Sokolovsky writes: > > > That's good news, but I meant something else. Having > > > different gcc settings between mingw and cygwin will > > > complicate binary portability between them - and I for sure > > > yet would like to think what is more important - > > > compatibility with foreign compiler or compatibility among > > > win32 versions of gcc. > > > > But isn't it so that you shouldn't be mixing code using > > different C runtime (msvcrt vs. cygwin) in an app and the DLLs > > it uses anyway? > > > > Yes, you cannot mix msvcrt and cygwin runtimes in an executable. > Cygwin is too dependant on Newlib's reentrancy coding to mix the > two runtimes. Thanks for clarifying that, Earnie. > And for MinGW, "compatibility amount win32 > versions of gcc" sounds like it's a must. I agree. > Although, I'm not sure > of what "complicate binary portability" problems would exist. My hunch is that it would be a major mess...not something I care to think about...;-) Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Earnie B. <ear...@ya...> - 2000-11-09 13:52:27
|
--- Paul Sokolovsky <pa...@is...> wrote: > > Nonetheless, GTK+ is important piece of software, and my attitudes > lean towards listening what its maintainers want ;-) We'll have > question of putting -fnative-struct in spec voted - if it's possible > to use -fnative-struct to have msvc compatibity, it will be quite > possible to use -fno-native-struct to get cygwin compatibity. > "Cygwin compatibility" isn't an issue. Cygwin would simply build it's own version. Cygwin will most likely not be able to use a MinGW built library anyway unless perhaps it's a static library and then it should be able to use it anyway. Can someone on this list provide a simple test case please? Cheers, ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ |
From: Tor L. <tm...@ik...> - 2000-11-09 14:27:02
|
> Can someone on this list provide a simple test case please? For what -fnative-struct does? koe3.c: #include <stdio.h> struct s { short i0; int i1 :2; int i3; }; main (int argc, char **argv) { printf ("sizeof (struct s) = %d\n", sizeof (struct s)); return 0; } $ gcc -o koe3 koe3.c $ ./koe3 sizeof (struct s) = 8 $ gcc -fnative-struct -o koe3 koe3.c $ ./koe3 sizeof (struct s) = 12 $ cl -MD -nologo koe3.c koe3.c $ ./koe3 sizeof (struct s) = 12 IIRC, what -fnative-struct affects is the alignment of a bitfield that follows a field that is smaller than the "base type" (correct terminology unclear to me) of the bitfield. Cheers, --tml |
From: <dan...@ya...> - 2000-11-10 06:00:27
|
--- Paul Sokolovsky <pa...@is...> wrote: > Hello Tor, > > Tor Lillqvist <tm...@ik...> wrote on Wednesday, November 08, 2000: > > TL> Paul Sokolovsky writes: > TL> > That's good news, but I meant something else. Having different > gcc > TL> > settings between mingw and cygwin will complicate binary > portability > TL> > between them - and I for sure yet would like to think what is > more > TL> > important - compatibility with foreign compiler or > compatibility among > TL> > win32 versions of gcc. > > TL> But isn't it so that you shouldn't be mixing code using different > C > TL> runtime (msvcrt vs. cygwin) in an app and the DLLs it uses > anyway? > > Yes. But when I have cygwin app and only mingw dll, I at least > *can* try. With that change, there will be yet another reason why > this > may not work. Not big loss, indeed. I guess, we will need to vote for > inclusion -fnative-struct in spec. > > TL> --tml > > Unless we see some concrete examples of: 1) what -fnative-struct fixes 2) what -fnative-struct breaks 3) what it costs how can we make a rational decision? Danny _____________________________________________________________________________ http://clubs.yahoo.com.au - Yahoo! Clubs - Join a club or build your own! |
From: Franco B. <fra...@gm...> - 2000-11-10 07:03:23
|
Am Fre, 10 Nov 2000 schrieb Danny Smith: >Unless we see some concrete examples of: >1) what -fnative-struct fixes >2) what -fnative-struct breaks >3) what it costs >how can we make a rational decision? >Danny I agree. ------------------------------------- Out of the discussion so far, I get the impression that -fnative-struct makes it possible to share structs (or pointers to structs) between MSVC and gcc. OTOH it breaks sharing structs with non -fnative-struct code. As it only seems to change the data-allignment it should only cost a little binary-size (increasing the size of binaries using const structs). Also the dynamically allocated structs are larger, thus the program wastes a little RAM. But at the same time it might increase the performance of the program, as some ix86 processors handle alligned data faster than non-alligned data. Am I correct ? Ciao, Franco |
From: Greg C. <chi...@mi...> - 2000-11-10 19:02:15
|
Franco Bez wrote: > > Am Fre, 10 Nov 2000 schrieb Danny Smith: > >Unless we see some concrete examples of: > >1) what -fnative-struct fixes > >2) what -fnative-struct breaks > >3) what it costs > >how can we make a rational decision? > >Danny > > I agree. There's a testcase here: http://gcc.gnu.org/ml/gcc-patches/1999-06n/msg00702.html > Out of the discussion so far, I get the impression that -fnative-struct > makes it possible to share structs (or pointers to structs) between MSVC and > gcc. > > OTOH it breaks sharing structs with non -fnative-struct code. Is there really a universal ABI for win32? Does anyone know whether the other win32 compilers behave the same as MSVC? The URL quoted above says: | Note: gcc would have to treat "long double" as a 64-bit type | to get structures containing "long double" to match MSVC. | It was (currently) felt that having long double be an 80 bit type | was preferable, since double does the job nicely. Currently sizeof(long double) is 12, and I for one wouldn't want it changed to 8 bytes. If mingw needs that for complete ABI compatibility, then is the -fnative-struct step toward partial compatibility worthwhile? It seems that this step would help one important package. If I understand it correctly, it makes mingw/gcc-compiled binaries linkable with code compiled with msvc. Is it needed if, instead of using the ms compiler at all, everything is instead built with mingw/gcc? Even if so, why not just use the native_struct attribute in the gtk headers? I assume that's implemented because this program struct foo{char a;} __attribute__ ((native_struct)); compiles, although I didn't test what it does. > As it only seems to change the data-allignment it should only cost a little > binary-size (increasing the size of binaries using const structs). Also the > dynamically allocated structs are larger, thus the program wastes a little RAM. > > But at the same time it might increase the performance of the program, as some > ix86 processors handle alligned data faster than non-alligned data. Don't the packed and aligned attributes already give the programmer the ability to trade compactness versus performance? Does anyone use bitfields anyway if performance is critical? |
From: Tor L. <tm...@ik...> - 2000-11-10 22:22:13
|
Greg Chicares writes: > Currently sizeof(long double) is 12, and I for one wouldn't > want it changed to 8 bytes. If mingw needs that for complete > ABI compatibility, then is the -fnative-struct step toward > partial compatibility worthwhile? Good point. For gtk interoperability, -fnative-struct is essential, but sizeof (long double) isn't. > Is it needed if, instead of using the ms compiler at all, > everything is instead built with mingw/gcc? We, the people on this list, obviously prefer to use gcc (mingw). But the point is that there are lots of people who, for one or another reason, want or have to use MSVC for their code. They still would benefit from being able to use gcc-compiled generic libraries. > Even if so, why not just use the native_struct attribute in the gtk > headers? > struct foo{char a;} __attribute__ ((native_struct)); Mainly because I didn't want to clutter the gtk headers with strange stuff that would annoy the core (non-Win32) developers. Although, at that time I was thinking of having to mark each problematic bitfield with some __attribute__ which would have been much uglier. I didn't know of the native_struct __attribute__... That __attribute__ for the whole struct doesn't look so bad, it would be just one macro call after the struct declarations in question. The risk is just that you don't find all the structs that need to be marked... I prefer the global -fnative-struct. --tml |
From: Paul S. <pa...@is...> - 2000-11-07 23:32:25
|
Hello Earnie, Earnie Boyd <ear...@ya...> wrote: >> EB> Would it make since to add this switch to the GCC default specs file? >> >> That's what I think about too. Cygwin compatibility is issue to >> think about however. Well, and generally - gcc compatibility issue at >> all. >> EB> I'm of the opinion that MinGW support from Cygwin should be a full canadian EB> cross. So, if I have Cygwin then I should have to use `configure EB> --host=mingw32' in order to build it and the cross generated tools would handle EB> the build. I would really like to eliminate the -mno-cygwin hack for MinGW EB> support. BTW, I've held this opinion for several years. That's good news, but I meant something else. Having different gcc settings between mingw and cygwin will complicate binary portability between them - and I for sure yet would like to think what is more important - compatibility with foreign compiler or compatibility among win32 versions of gcc. EB> Cheers, EB> ===== EB> Earnie Boyd EB> mailto:ear...@ya... -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Jeff S. <jef...@ap...> - 2000-11-08 00:15:35
|
Paul Sokolovsky wrote: > That's good news, but I meant something else. Having different gcc > settings between mingw and cygwin will complicate binary portability > between them - and I for sure yet would like to think what is more > important - compatibility with foreign compiler or compatibility among > win32 versions of gcc. That makes sense. I can see having different _runtimes_ for Win32... that's what we have now with Cygwin and Mingw. It makes less sense to have different compilers. Among other things, I don't think the Cygwin gcc is build with --enable-threads. That makes it useless to me for Mingw builds. But I suspect Cygwin users aren't too interested in thread safety. -- Jeff Sturm jef...@co... |
From: Tor L. <tm...@ik...> - 2000-11-08 18:22:05
|
Paul Sokolovsky writes: > That's good news, but I meant something else. Having different gcc > settings between mingw and cygwin will complicate binary portability > between them - and I for sure yet would like to think what is more > important - compatibility with foreign compiler or compatibility among > win32 versions of gcc. But isn't it so that you shouldn't be mixing code using different C runtime (msvcrt vs. cygwin) in an app and the DLLs it uses anyway? --tml |
From: Paul S. <pa...@is...> - 2000-11-08 19:58:37
|
Hello Tor, Tor Lillqvist <tm...@ik...> wrote on Wednesday, November 08, 2000: TL> Paul Sokolovsky writes: TL> > That's good news, but I meant something else. Having different gcc TL> > settings between mingw and cygwin will complicate binary portability TL> > between them - and I for sure yet would like to think what is more TL> > important - compatibility with foreign compiler or compatibility among TL> > win32 versions of gcc. TL> But isn't it so that you shouldn't be mixing code using different C TL> runtime (msvcrt vs. cygwin) in an app and the DLLs it uses anyway? Yes. But when I have cygwin app and only mingw dll, I at least *can* try. With that change, there will be yet another reason why this may not work. Not big loss, indeed. I guess, we will need to vote for inclusion -fnative-struct in spec. TL> --tml -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Paul G. <pga...@te...> - 2000-11-08 23:53:06
|
On 8 Nov 2000, at 21:57, the Illustrious Paul Sokolovsky wrote: > Hello Tor, > > Tor Lillqvist <tm...@ik...> wrote on Wednesday, November 08, 2000: > > TL> Paul Sokolovsky writes: > TL> > That's good news, but I meant something else. Having > different gcc TL> > settings between mingw and cygwin will > complicate binary portability TL> > between them - and I for > sure yet would like to think what is more TL> > important - > compatibility with foreign compiler or compatibility among TL> > > win32 versions of gcc. > > TL> But isn't it so that you shouldn't be mixing code using > different C TL> runtime (msvcrt vs. cygwin) in an app and the > DLLs it uses anyway? > > Yes. But when I have cygwin app and only mingw dll, I at > least > *can* try. With that change, there will be yet another reason why > this may not work. Not big loss, indeed. I guess, we will need to > vote for inclusion -fnative-struct in spec. It looks like it. I, personally, have serious doubts about including it as part of default specs. Primarily due to the fact that I have not ever needed to use it in the years I've been porting stuff for Mingw. Secondarily, it adds a level of complication that, as far as I can tell, completely unnecessary unless there is a clearly defined requirement for such a thing based on the number of people who actually use the -fnative-struct switch. Finally, if someone really understands what -fnative-struct switch does, then they are probably very capable of opening their favorite editor and modifying their own spec file accordingly. In closing, It doesn't make sense to force the use of the -fnative-switch, or to make it available as part of default spec file. So, if it came down to a vote, I would say "no". Peace, Paul G. > > TL> --tml > > > -- > Paul Sokolovsky, IT Specialist > http://www.brainbench.com/transcript.jsp?pid=11135 > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/mailman/listinfo/mingw-users > Nothing real can be threatened. Nothing unreal exists. |