From: Earnie B. <ear...@ya...> - 2000-11-07 16:40:48
|
--- Tor Lillqvist <tm...@ik...> wrote: > Are the DLLs available from the mingw32 packages repository on > SourceForge compiled with -fnative-struct? This would be necessary so > that the same DLLs (and headers) can also be used by people using > MSVC. The differences in struct packing between gcc (when not using > this flag) might in fact not affect the ABI of the currently available > libraries, but IMHO it's best to use it all the time anyway. > > You do want the libraries on mingwrep to be usable from MSVC-compiled > code, too, don't you? > Would it make since to add this switch to the GCC default specs file? 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 14:29:02
|
--- Paul Garceau <pga...@te...> wrote: > > > On 7 Nov 2000, at 8:40, the Illustrious Earnie Boyd wrote: > > > --- Tor Lillqvist <tm...@ik...> wrote: > > > Are the DLLs available from the mingw32 packages repository on > > > SourceForge compiled with -fnative-struct? This would be > > > necessary so that the same DLLs (and headers) can also be used > > > by people using MSVC. The differences in struct packing between > > > gcc (when not using this flag) might in fact not affect the ABI > > > of the currently available libraries, but IMHO it's best to use > > > it all the time anyway. > > > > > > You do want the libraries on mingwrep to be usable from > > > MSVC-compiled code, too, don't you? > > > > > > > Would it make since to add this switch to the GCC default specs > > file? > > I don't think so. Not everyone is building stuff to be > compatible with msvc compiled code. In fact, I know of quite a > few people who are not. > The only reason to include the -fnative-struct switch is if > your app is somehow dependent on msvc compiled .dlls. To a > degree, this is valid. Ok. I see your point. > However, mingw is, as we well know, not msvc. In fact, as I > recall, Mingw appeared because many people desired to build > win32api applications w/o having to (please forgive the > graphical metaphors) rely on MS pap or to pay MS to suckle their > profferred SDKs. No! Colin Peters started MinGW by providing a set of headers to allow the use of the CRTDLL/MSVCRT runtimes instead of the Cygwin runtime. JanJaap then ported gcc to those runtimes due to the conflicts stated in the Cygwin license at the time he ported it. Mumit picked up the gcc porting and provided ports of current releases for Cygwin, UWIN and MinGW. > It is a good thing to be able to interface with the msvc > compiled code, but it should not be set as part of the default > specs for gcc/++, not by any means. Understood. > If someone needs this capability for integration purposes, then > it should, instead, be made clear, somewhere, that if they want > to interface with the msvc compiled code, then they "must" use > the -fnative-struct switch. > Sounds like a job you can do. ;^) 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:42:55
|
On 8 Nov 2000, at 6:29, the Illustrious Earnie Boyd wrote: > --- Paul Garceau <pga...@te...> wrote: > > > > > > On 7 Nov 2000, at 8:40, the Illustrious Earnie Boyd wrote: > > > > > --- Tor Lillqvist <tm...@ik...> wrote: > > > > Are the DLLs available from the mingw32 packages repository > > > > on SourceForge compiled with -fnative-struct? This would be > > > > necessary so that the same DLLs (and headers) can also be > > > > used by people using MSVC. The differences in struct > > > > packing between gcc (when not using this flag) might in > > > > fact not affect the ABI of the currently available > > > > libraries, but IMHO it's best to use it all the time > > > > anyway. > > > > > > > > You do want the libraries on mingwrep to be usable from > > > > MSVC-compiled code, too, don't you? > > > > > > > > > > Would it make since to add this switch to the GCC default > > > specs file? > > > > I don't think so. Not everyone is building stuff to be > > compatible with msvc compiled code. In fact, I know of quite a > > few people who are not. The only reason to include the > > -fnative-struct switch is if your app is somehow dependent on > > msvc compiled .dlls. To a degree, this is valid. > > Ok. I see your point. > > > However, mingw is, as we well know, not msvc. In fact, as I > > recall, Mingw appeared because many people desired to build > > win32api applications w/o having to (please forgive the > > graphical metaphors) rely on MS pap or to pay MS to suckle > > their profferred SDKs. > > No! Colin Peters started MinGW by providing a set of headers to > allow the use of the CRTDLL/MSVCRT runtimes instead of the Cygwin > runtime. JanJaap then ported gcc to those runtimes due to the > conflicts stated in the Cygwin license at the time he ported it. > Mumit picked up the gcc porting and provided ports of current > releases for Cygwin, UWIN and MinGW. I stand corrected. Even so, the mingw runtime only Interfaces with the crtdll/msvcrt, they are not directly compatible. I seem to remember one time, some while ago, when I did a comparison of the gcc output executable and an msvc output executable...they did not match. > > > It is a good thing to be able to interface with the msvc > > compiled code, but it should not be set as part of the default > > specs for gcc/++, not by any means. > > Understood. Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Tor L. <tm...@ik...> - 2000-11-09 07:08:44
|
> I seem to remember one time, some while ago, when I did a > comparison of the gcc output executable and an msvc output > executable...they did not match. Well, you wouldn't really expect two compilers to produce identical code, would you? > > > It is a good thing to be able to interface with the msvc > > > compiled code, but it should not be set as part of the default > > > specs for gcc/++, not by any means. I disagree here. (And let's keep C++ out of this discussion, interoperability between C++ code compiled by different compilers is mostly impossible anyway.) To get back to another question discussed some time ago, "What *is* MinGW"... www.mingw.org says: "MinGW is a collection of header files and import libraries that allow one to use GCC and produce native Windows32 programs that do not rely on any 3rd-party DLLs." To me, this clearly indicates that the term "mingw" names a *build* environment only. The *target* environment is Win32, and its msvcrt or crtdll C runtimes. There is no mingw runtime environment. (Oh well, there is a libmingw32.a, but I don't think one should think of that as a runtime environment, it's mostly compiler-specific startup code. Except for the dirent functions, which I BTW think shouldn't be there, but in a separate DLL, so that it would be a generic dirent implementation, also usable from MSVC-compiled code.) Thus IMHO talking about "ports to Mingw32" is a bit misleading. But if it is understood to mean "ports to the mingw32 build environment" it's OK. But really, how many people are interested in rebuilding some common library themselves, if it is available ready-built? Anyway, I think that mingwrep should really more profile itself as a repository for canonical Windows ports of common Open Source libraries, and make the libraries usable by MSVC users, too. (One could see this as a way to lure MSVC users into the Open Source mindset...) In addition to compiling with -fnative-struct, this means providing import libraries in .lib format, too. (The freely (as in $0.00) available PlatformSDK includes tools to produce them.) (No, I don't think that mingwrep needs to provide nmake makefiles or, shock horror, MSVC workspaces or whatever they are called.) > 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. What spec file? If your average point-and-click MSVC developer is looking for a ready-built Windows port of <insert favourite open source library here>, do we want her to think "Oh great, this nifty library is available here. But oh no, these open source guys on purpose have made it not binary compatible with my compiler. They are just like Microsoft. I guess I'll just have to spend a week building it myself then, or buy it from some commercial redistributor"? Anyway, this whole -fnative-struct question might not be relevant for most libraries except gtk... Does anybody have a guess how many libraries in their API use the kinds of structs that are allocated differently with -fnative-struct? --tml |
From: Franco B. <fra...@gm...> - 2000-11-09 09:36:41
|
I was following the discussion on the -fnative-structs switch, and I must say that I'm a bit confused. Maybe someone could clarify the following: 1. Are there any known problems/bugs in the -fnative-structs (produced) code ? 2. Is it neccessary to rebuilt the mingw-runtime environment (the libs) in order to use -fnative-structs 3. Is the performance, or the size of the resulting binaries affected by the -fnative-structs switch If -fnative-structs increases the compatibility between the native-Windows C-Compilers I'd vote to indeed use it by default. IMO mixing Cygwin and mingw libraries and DLL's will allways produce problems, so that loosing a little more (binary) compatibillity to Cygwin won't hurt. If OTOH we could fix some of the hard to trackdown bugs (mostly Access violations / run time crashes) resulting in mixing MSVC/Borland/mingw DLLs and libs, by simply adding a small switch to gcc's spec file - this will definately add more value to mingw. Ciao, Franco |
From: Paul S. <pa...@is...> - 2000-11-09 10:09:36
|
Hello Tor, Tor Lillqvist <tm...@ik...> wrote on Thursday, November 09, 2000: TL> Anyway, I think that mingwrep should really more profile itself as a TL> repository for canonical Windows ports of common Open Source TL> libraries, and make the libraries usable by MSVC users, too. (One TL> could see this as a way to lure MSVC users into the Open Source TL> mindset...) Yep, I have such ambition ;-) TL> In addition to compiling with -fnative-struct, this means TL> providing import libraries in .lib format, too. (The freely (as in TL> $0.00) available PlatformSDK includes tools to produce them.) But for this, sorry - I simply do not use it. Whole mingwrep thing started with the hope to organize contribution infrastructure. I wouldn't like to stuff .lib into existing packages, but happily put them into contrib on ftp and put link to them on site (and each package has link to the site). So, if you'll be doing that, you're welcome to contribute. TL> Anyway, this whole -fnative-struct question might not be relevant for TL> most libraries except gtk... Does anybody have a guess how many TL> libraries in their API use the kinds of structs that are allocated TL> differently with -fnative-struct? Per my perception, simply *none*. At least, I don't remember seeing it in "canonical" GNU software. I don't remember whether GNU Coding Standards mention bitfields expliciitly, but it clearly recommends not to use novelty syntax if the same semantics can be achieved without much pain via standard constructions. 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. TL> --tml -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Earnie B. <ear...@ya...> - 2000-11-14 13:21:29
|
--- Greg Chicares <chi...@mi...> wrote: > > There's a testcase here: > http://gcc.gnu.org/ml/gcc-patches/1999-06n/msg00702.html > Can someone please tell me if Don Terry's patch referenced above was applied? 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!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ |
From: Paul S. <pa...@is...> - 2000-11-07 21:17:48
|
Hello Earnie, Earnie Boyd <ear...@ya...> wrote: EB> --- Tor Lillqvist <tm...@ik...> wrote: >> Are the DLLs available from the mingw32 packages repository on >> SourceForge compiled with -fnative-struct? This would be necessary so >> that the same DLLs (and headers) can also be used by people using >> MSVC. The differences in struct packing between gcc (when not using >> this flag) might in fact not affect the ABI of the currently available >> libraries, but IMHO it's best to use it all the time anyway. That's exactly the state it has now: 1) it wasn't used; 2) I don't think it can bite with the libraries which currently there; 3) it should be used. >> You do want the libraries on mingwrep to be usable from MSVC-compiled >> code, too, don't you? Yes. And I personally would be happy to see them usable for gtk-win32, too ;-) 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> Cheers, EB> ===== EB> Earnie Boyd EB> mailto:ear...@ya... -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Tor L. <tm...@ik...> - 2000-11-08 18:15:45
|
> --- Tor Lillqvist <tm...@ik...> wrote: > >> You do want the libraries on mingwrep to be usable from MSVC-compiled > >> code, too, don't you? Paul Sokolovsky writes: > Yes. And I personally would be happy to see them usable for > gtk-win32, too ;-) Good! I most probably will start using (and redistributing) them! One thing about the libtiff, though. There really should be two version (but with the same name for the DLL): One with LZW code (for those who are not afraid of Unisys's lawyers), one without... (the same name for both DLLs so that you can add/remove LZW support just by replacing the libtiff DLL, without having to relink applications). --tml |
From: Paul S. <pa...@is...> - 2000-11-08 20:00:30
|
Hello Tor, Tor Lillqvist <tm...@ik...> wrote on Wednesday, November 08, 2000: >> --- Tor Lillqvist <tm...@ik...> wrote: TL> > >> You do want the libraries on mingwrep to be usable from MSVC-compiled TL> > >> code, too, don't you? TL> Paul Sokolovsky writes: TL> > Yes. And I personally would be happy to see them usable for TL> > gtk-win32, too ;-) TL> Good! I most probably will start using (and redistributing) them! Good news! TL> One thing about the libtiff, though. There really should be two version TL> (but with the same name for the DLL): One with LZW code (for those who TL> are not afraid of Unisys's lawyers), one without... (the same name for TL> both DLLs so that you can add/remove LZW support just by replacing the TL> libtiff DLL, without having to relink applications). Do you think this issue is top-priority (i.e., presupposition for starting to use them)? I'm going to finish with binutils hacking and turn back to gtk+/win32. TL> --tml -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Tor L. <tm...@ik...> - 2000-11-09 06:34:02
|
> TL> One thing about the libtiff, though. There really should be two version > TL> (but with the same name for the DLL): One with LZW code (for those who > TL> are not afraid of Unisys's lawyers), one without... (the same name for > TL> both DLLs so that you can add/remove LZW support just by replacing the > TL> libtiff DLL, without having to relink applications). Paul Sokolovsky writes: > Do you think this issue is top-priority (i.e., presupposition for > starting to use them)? For libtiff, no. I can continue using a static libtiff until both a LZW and non-LZW libtiff DLL is available. --tml |
From: Paul G. <pga...@te...> - 2000-11-08 00:33:22
|
On 7 Nov 2000, at 8:40, the Illustrious Earnie Boyd wrote: > --- Tor Lillqvist <tm...@ik...> wrote: > > Are the DLLs available from the mingw32 packages repository on > > SourceForge compiled with -fnative-struct? This would be > > necessary so that the same DLLs (and headers) can also be used > > by people using MSVC. The differences in struct packing between > > gcc (when not using this flag) might in fact not affect the ABI > > of the currently available libraries, but IMHO it's best to use > > it all the time anyway. > > > > You do want the libraries on mingwrep to be usable from > > MSVC-compiled code, too, don't you? > > > > Would it make since to add this switch to the GCC default specs > file? I don't think so. Not everyone is building stuff to be compatible with msvc compiled code. In fact, I know of quite a few people who are not. The only reason to include the -fnative-struct switch is if your app is somehow dependent on msvc compiled .dlls. To a degree, this is valid. However, mingw is, as we well know, not msvc. In fact, as I recall, Mingw appeared because many people desired to build win32api applications w/o having to (please forgive the graphical metaphors) rely on MS pap or to pay MS to suckle their profferred SDKs. It is a good thing to be able to interface with the msvc compiled code, but it should not be set as part of the default specs for gcc/++, not by any means. If someone needs this capability for integration purposes, then it should, instead, be made clear, somewhere, that if they want to interface with the msvc compiled code, then they "must" use the -fnative-struct switch. Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Tor L. <tm...@ik...> - 2000-11-08 19:02:06
|
Paul Garceau writes: > I don't think so. Not everyone is building stuff to be > compatible with msvc compiled code. In fact, I know of quite a > few people who are not. But for generally useful more or less well-known libraries like zlib, jpeg, tiff, iconv, glib, gtk+ etc is there really any reason not to have them 100% usable also from MSVC code. > The only reason to include the -fnative-struct switch is if > your app is somehow dependent on msvc compiled .dlls. Or more importantly (IMHO), make your DLL available also to MSVC users. > However, mingw is, as we well know, not msvc. But it uses the same runtime. > In fact, as I recall, Mingw appeared because many people desired to > build win32api applications w/o having to (please forgive the > graphical metaphors) rely on MS pap or to pay MS to suckle their > profferred SDKs. The MS "Platform SDK" is available for free... but I digress. --tml |