* open watcom compiling gcc on win32 @ 2004-01-27 8:02 Edward S. Peschko 2004-01-27 8:53 ` Marcel Cox 0 siblings, 1 reply; 22+ messages in thread From: Edward S. Peschko @ 2004-01-27 8:02 UTC (permalink / raw) To: gcc hey, I was wondering if open-watcom could be used to compile gcc on win32... I was hoping to do so under cygwin.. If so, what are the steps for doing so? If not, what's the preferred compiler for building gcc on win32? Thanks much, Ed ( ps - have the gcc folks looked at the watcom code? I know its not completely GPL compatible, but I'm sure that some sort of agreement could be made with Sybase to let gcc encorporate ideas from watcom... well, its worth a try anyway. The personal thing I want to see is compatibilty with VC++ 6.0 on win32 - which Watcom has and g++ of course lacks. I know is discussed in the FAQ - however, I'm really scratching my head on how to use cygwin to talk to stuff like oracle and certain oracle tools in a performance acceptable way. ) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-27 8:02 open watcom compiling gcc on win32 Edward S. Peschko @ 2004-01-27 8:53 ` Marcel Cox 2004-01-27 18:38 ` Edward S. Peschko 0 siblings, 1 reply; 22+ messages in thread From: Marcel Cox @ 2004-01-27 8:53 UTC (permalink / raw) To: gcc Edward S. Peschko wrote: > I was wondering if open-watcom could be used to compile gcc on > win32... I was hoping to do so under cygwin.. > > If so, what are the steps for doing so? If not, what's the preferred > compiler for building gcc on win32? You should take a look at the Mingw32 project which is a native GCC port to win32 platforms: http://www.mingw.org/ -- Marcel (using XanaNews 1.16.1.3) I can resist everything but temptation ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-27 8:53 ` Marcel Cox @ 2004-01-27 18:38 ` Edward S. Peschko 2004-01-28 20:29 ` Marcel Cox 0 siblings, 1 reply; 22+ messages in thread From: Edward S. Peschko @ 2004-01-27 18:38 UTC (permalink / raw) To: Marcel Cox; +Cc: gcc On Tue, Jan 27, 2004 at 08:00:51AM +0000, Marcel Cox wrote: > Edward S. Peschko wrote: > > > I was wondering if open-watcom could be used to compile gcc on > > win32... I was hoping to do so under cygwin.. > > > > If so, what are the steps for doing so? If not, what's the preferred > > compiler for building gcc on win32? > > You should take a look at the Mingw32 project which is a native GCC > port to win32 platforms: > > http://www.mingw.org/ > well, that's the point - I need a compiler that can link with VC++ dlls *and* compile the gnu toolchain. Right now, both python and perl are split into two 'personalities' : you can either compile modules *for* win32 or modules *for* unix, but you can't do both and hope to have them play well together. Plus, certain third-party APIs don't work well with mingw - well, pretty much all third-party APIs don't work well because they are all compiled for Borland or VC++. And COM just plain sucks - most tool people assume that you have VC++ or Borland. So, as far as I see it, watcom is the only viable choice for what I want to do. And if I could compile gcc with watcom, I could pretty much compile anything gnu-like. Ed ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-27 18:38 ` Edward S. Peschko @ 2004-01-28 20:29 ` Marcel Cox 2004-01-29 23:32 ` Edward S. Peschko 0 siblings, 1 reply; 22+ messages in thread From: Marcel Cox @ 2004-01-28 20:29 UTC (permalink / raw) To: gcc Edward S. Peschko wrote: > I need a compiler that can link with VC++ dlls and compile the gnu > toolchain. Right now, both python and perl are split into two > 'personalities' : you can either compile modules for win32 or modules > for unix, but you can't do both and hope to have them play well > together. > > Plus, certain third-party APIs don't work well with mingw - well, > pretty much all third-party APIs don't work well because they are all > compiled for Borland or VC++. And COM just plain sucks - most tool > people assume that you have VC++ or Borland. > > So, as far as I see it, watcom is the only viable choice for what I > want to do. And if I could compile gcc with watcom, I could pretty > much compile anything gnu-like. Actually, your problem is not so much the compiler itself as the make machinery and the APIs available. In fact, most of the gnu-like programs do not rely on any special GCC features or extensions. However most of them are based on automake/autoconf style configuration scripts that presuppose a Unix like environment to run, and many of the applications are written close to Posix APIs and often call functions that are not natively available on Windows. To solve the first problem, there are 2 kind of approaches: - either you create a Unix like shell environment with the associated tools under Windows. This has both been done in the Cygwin and the Mingw project - the other solution is to create new make or project files specific for the development environment you have. An example of this can for example be seen in the Ethereal project where there are automatic configuration scripts for Unix like environments and a finished make for for use with MSVC++ The second problem (Posix compatibility) is generall more tough to solve. You either have to develop to a Posix emulation library (like Cygwin) or you have to do a major rewrite of the projects by replcing Posix style constructs with their more or less equivalent Windows functionality. -- Marcel Cox (using XanaNews 1.16.1.3) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-28 20:29 ` Marcel Cox @ 2004-01-29 23:32 ` Edward S. Peschko 2004-01-29 23:51 ` DJ Delorie 2004-01-30 0:26 ` Jonathan Wilson 0 siblings, 2 replies; 22+ messages in thread From: Edward S. Peschko @ 2004-01-29 23:32 UTC (permalink / raw) To: Marcel Cox; +Cc: gcc > > So, as far as I see it, watcom is the only viable choice for what I > > want to do. And if I could compile gcc with watcom, I could pretty > > much compile anything gnu-like. > Actually, your problem is not so much the compiler itself as the make > machinery and the APIs available. > The second problem (Posix compatibility) is generall more tough to > solve. You either have to develop to a Posix emulation library (like > Cygwin) or you have to do a major rewrite of the projects by replcing > Posix style constructs with their more or less equivalent Windows > functionality. well, I have no problem *using* cygwin or dynamically linking a cygwin.dll. But - the cygwin dll that I produce has to 'play well' with vc++ dlls. And *that's* what watcom provides. In fact, that was what I was planning on doing. Compiling cygwin with watcom to produce a vc++ compatible cygwin dll. And what I'm saying is that is what gcc should provide. gcc, ld, ar, as, on win32 should produce visual C++ compatible dlls. Borland does it, watcom does it.. I don't know if the intel compiler does it, but I bet it does - VC++, 6 and above, is the standard by default on those platforms. And since watcom is open source, it points the path on how to do it - no reverse engineering needed. I already talked to the watcom folks; the license explicitly allows people to look at the code and reverse engineer concepts. They might be mad if whole sections of code were taken and encorporated into gcc outright, but I doubt that would even be feasible in the first place. Ed ( ps - apparently watcom 1.2 compatibility with VC++ is pretty damn good, ie production ready or approaching it. At least that's what I surmised when googling for it, and asking around. Although I admit I have a small sample (5 'works fine for me's' and one resolved production problem.) In any case, its something to check out. Here's one thread: http://makeashorterlink.com/?U29316D37 ) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-29 23:32 ` Edward S. Peschko @ 2004-01-29 23:51 ` DJ Delorie 2004-01-30 0:29 ` Edward S. Peschko 2004-01-30 0:37 ` Jonathan Wilson 2004-01-30 0:26 ` Jonathan Wilson 1 sibling, 2 replies; 22+ messages in thread From: DJ Delorie @ 2004-01-29 23:51 UTC (permalink / raw) To: esp5; +Cc: gcc > But - the cygwin dll that I produce has to 'play well' with vc++ dlls. > And *that's* what watcom provides. In fact, that was what I was planning on > doing. Compiling cygwin with watcom to produce a vc++ compatible cygwin dll. > > And what I'm saying is that is what gcc should provide. gcc, ld, ar, as, on win32 > should produce visual C++ compatible dlls. At this point, you've left the realm of gcc and wandered into either the binutils realm, or the cygwin realm. The mechanisms for producing DLLs are in binutils (specifically, the linker "ld"), and the policy for making cygwin1.dll specifically rests with the cygwin project. http://sources.redhat.com/binutils/ http://www.cygwin.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-29 23:51 ` DJ Delorie @ 2004-01-30 0:29 ` Edward S. Peschko 2004-01-30 0:45 ` DJ Delorie 2004-01-30 0:37 ` Jonathan Wilson 1 sibling, 1 reply; 22+ messages in thread From: Edward S. Peschko @ 2004-01-30 0:29 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc On Thu, Jan 29, 2004 at 06:46:04PM -0500, DJ Delorie wrote: > > > But - the cygwin dll that I produce has to 'play well' with vc++ dlls. > > And *that's* what watcom provides. In fact, that was what I was planning on > > doing. Compiling cygwin with watcom to produce a vc++ compatible cygwin dll. > > > > And what I'm saying is that is what gcc should provide. gcc, ld, ar, as, on win32 > > should produce visual C++ compatible dlls. > > At this point, you've left the realm of gcc and wandered into either > the binutils realm, or the cygwin realm. The mechanisms for producing > DLLs are in binutils (specifically, the linker "ld"), and the policy > for making cygwin1.dll specifically rests with the cygwin project. well, no, I wouldn't say that I've 'left the realm of gcc' - after all, the objects that gcc produce, and how certain features of g++ on win32 work (RTTI, etc) would need to change and have to work smoothly with ld, and I would argue that it is a *steering committee* decision that could prompt such a change in cygwin. And the suggestions I got from some members of the mingw group was to talk to the gcc steering committee. So here I am. And in any case, its a point in the g++ FAQ that I'm disputing: http://docs.freebsd.org/info/g++FAQ/g++FAQ.info.problems_linking_with_other_libraries.html I'd say this holds true for unix, untrue for win32. Ed ( ps - I'll talk to the binutils group as you suggest.. however, in order for this to work the three groups would have to work together. which sort of doesn't leave me too much hope that it will happen.. however, there are other reasons for looking at watcom - optimisation being one of the primary ones. A command decision has to be made, and perhaps the will will be found and a set of gnu tools that produces vc++-linkable libraries will be implemented along the way. This could be slightly optimistic though.. ;-) ) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 0:29 ` Edward S. Peschko @ 2004-01-30 0:45 ` DJ Delorie 2004-01-30 1:20 ` Edward S. Peschko 0 siblings, 1 reply; 22+ messages in thread From: DJ Delorie @ 2004-01-30 0:45 UTC (permalink / raw) To: esp5; +Cc: gcc > well, no, I wouldn't say that I've 'left the realm of gcc' - after > all, the objects that gcc produce, and how certain features of g++ > on win32 work (RTTI, etc) would need to change and have to work > smoothly with ld, and I would argue that it is a *steering > committee* decision that could prompt such a change in cygwin. In that case, you weren't specific enough the first time around. To me, "objects" refers to object files, which the assembler (not gcc) produces. "Compatible" for dlls usually means the system can load them, tools can manipulate them, etc. ABI compatibility at the high level (C++) is a different story. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 0:45 ` DJ Delorie @ 2004-01-30 1:20 ` Edward S. Peschko 2004-01-30 17:41 ` Oscar Fuentes 0 siblings, 1 reply; 22+ messages in thread From: Edward S. Peschko @ 2004-01-30 1:20 UTC (permalink / raw) To: DJ Delorie; +Cc: gcc On Thu, Jan 29, 2004 at 07:37:41PM -0500, DJ Delorie wrote: > > > well, no, I wouldn't say that I've 'left the realm of gcc' - after > > all, the objects that gcc produce, and how certain features of g++ > > on win32 work (RTTI, etc) would need to change and have to work > > smoothly with ld, and I would argue that it is a *steering > > committee* decision that could prompt such a change in cygwin. > > In that case, you weren't specific enough the first time around. To > me, "objects" refers to object files, which the assembler (not gcc) > produces. "Compatible" for dlls usually means the system can load > them, tools can manipulate them, etc. ABI compatibility at the high > level (C++) is a different story. Ok, I wasn't being specific enough. That is exactly what I want - visual C++ ABI compatibility at the 'high level' on win32. In a capsule, my argument is that it opens up a world of possibility for gcc/g++ on win32, it is completely feasible through open watcom. so, how realistic is this? Ed ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 1:20 ` Edward S. Peschko @ 2004-01-30 17:41 ` Oscar Fuentes 2004-01-30 21:40 ` Edward S. Peschko 0 siblings, 1 reply; 22+ messages in thread From: Oscar Fuentes @ 2004-01-30 17:41 UTC (permalink / raw) To: gcc "Edward S. Peschko" <esp5@pge.com> writes: > Ok, I wasn't being specific enough. That is exactly what I want - > visual C++ ABI compatibility at the 'high level' on win32. > In a capsule, my argument is that it opens up a world of possibility for > gcc/g++ on win32, it is completely feasible through open watcom. How lack of MSVC++ ABI compatibility is hurting you? BTW, FYI, Borland is not C++ ABI compatible with MSVC++. > so, how realistic is this? In the 3.x series, g++ uses a "industry-standard" C++ ABI. The old ABI was abandoned due to the extra work required for its maintenance. Have you asked MS if they plan to support that standard C++ ABI ? ;-) I'm not a gcc developer and so I can't say how much work your proposal requires (a lot, I guess) but as a MinGW user I can't see where the benefit are, other than using pre-built MSVC++ C++ libraries. -- Oscar ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 17:41 ` Oscar Fuentes @ 2004-01-30 21:40 ` Edward S. Peschko 2004-01-30 22:21 ` Ian Lance Taylor 2004-02-01 14:43 ` Kai Henningsen 0 siblings, 2 replies; 22+ messages in thread From: Edward S. Peschko @ 2004-01-30 21:40 UTC (permalink / raw) To: Oscar Fuentes; +Cc: gcc On Fri, Jan 30, 2004 at 06:29:13PM +0100, Oscar Fuentes wrote: > "Edward S. Peschko" <esp5@pge.com> writes: > > > Ok, I wasn't being specific enough. That is exactly what I want - > > visual C++ ABI compatibility at the 'high level' on win32. > > In a capsule, my argument is that it opens up a world of possibility for > > gcc/g++ on win32, it is completely feasible through open watcom. > > How lack of MSVC++ ABI compatibility is hurting you? well it is hurting me.. Here's an example - Right now, the perl world on win32 is pretty much divided in half, with the cygwin perl on the one hand, and the activestate perl on the other. python is the same way. Hence, in order to do what I need to do, I need to maintain *two sets* of perls and pythons. And some modules work on activestate's, some modules work on cygwin. Hence, if I want to use expect in a script, I need to turn to cygwin. When I want to use Win32::AdminMisc, I need to turn to ActiveState. And if I need to bind to a third party API I need to turn to ActiveState. I don't want to maintain two separate distributions just because the compilers squawk with each other. I want things to be transparent. It costs me functionality because I can't both do Expect and Win32::AdminMisc in the same script, and because I can't link in certain third-party APIs (from Oracle, for instance.) If g++ was really smart, it would provide a compatibility mode which translated VC++ headers/etc into g++ (preferably STL) components, a 'crutch' for people who want to dump VC++ altogether. > BTW, FYI, Borland is not C++ ABI compatible with MSVC++. reference? I see different. http://shop.store.yahoo.com/1-software-group/borcbuil50en.html > > so, how realistic is this? > > In the 3.x series, g++ uses a "industry-standard" C++ ABI. The old ABI > was abandoned due to the extra work required for its maintenance. Have > you asked MS if they plan to support that standard C++ ABI ? ;-) yeah yeah yeah.. very funny... I would say that the standard by default is VC++. > I'm not a gcc developer and so I can't say how much work your proposal > requires (a lot, I guess) but as a MinGW user I can't see where the > benefit are, other than using pre-built MSVC++ C++ libraries. but that's just it. How many times have you had to link to proprietary APIs like winrunner and oracle app-works, or to control apps like photoshop? No offense intended, but as it is, for large software vendors gcc is really just a toy on win32 - it fits into its own little world, it might be nice to play with, but I don't see any large companies releasing APIs targetted at gcc/g++. I don't want it to be that way. I want to dump VC++ altogether and use gcc (since it is the compiler I use on unix). It is really annoying me that I can't, and that I'm forced to look for an alternative. (ie: watcom) Ed ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 21:40 ` Edward S. Peschko @ 2004-01-30 22:21 ` Ian Lance Taylor 2004-01-30 22:52 ` Devang Patel ` (2 more replies) 2004-02-01 14:43 ` Kai Henningsen 1 sibling, 3 replies; 22+ messages in thread From: Ian Lance Taylor @ 2004-01-30 22:21 UTC (permalink / raw) To: Edward S. Peschko; +Cc: Oscar Fuentes, gcc "Edward S. Peschko" <esp5@pge.com> writes: > > BTW, FYI, Borland is not C++ ABI compatible with MSVC++. > > reference? I see different. > > http://shop.store.yahoo.com/1-software-group/borcbuil50en.html I don't see anything there which says that the C++ ABI is the same. But I really have no information on the topic. On the other hand, I've heard several times that Microsoft has patented their vtable layout. That would make it impossible for gcc to emulate it, unless Microsoft gave explicit permission. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 22:21 ` Ian Lance Taylor @ 2004-01-30 22:52 ` Devang Patel 2004-01-30 22:53 ` Robert Dewar 2004-01-30 23:25 ` Edward S. Peschko 2004-01-30 23:55 ` tm_gccmail 2 siblings, 1 reply; 22+ messages in thread From: Devang Patel @ 2004-01-30 22:52 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Oscar Fuentes, gcc@gcc.gnu.org list, Edward S. Peschko On Jan 30, 2004, at 1:49 PM, Ian Lance Taylor wrote: > On the other hand, I've heard several times that Microsoft has > patented their vtable layout. http://patft.uspto.gov/netacgi/nph-Parser? Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ srchnum.htm&r=1&f=G&l=50&s1=5,297,284.WKU.&OS=PN/5,297,284&RS=PN/ 5,297,284 [ US Patent Number: 5,297,284] > That would make it impossible for gcc > to emulate it, unless Microsoft gave explicit permission -- Devang ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 22:52 ` Devang Patel @ 2004-01-30 22:53 ` Robert Dewar 0 siblings, 0 replies; 22+ messages in thread From: Robert Dewar @ 2004-01-30 22:53 UTC (permalink / raw) To: Devang Patel Cc: Ian Lance Taylor, Oscar Fuentes, gcc@gcc.gnu.org list, Edward S. Peschko Devang Patel wrote: > > On Jan 30, 2004, at 1:49 PM, Ian Lance Taylor wrote: > >> On the other hand, I've heard several times that Microsoft has >> patented their vtable layout. > > > http://patft.uspto.gov/netacgi/nph-Parser? > Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/ > srchnum.htm&r=1&f=G&l=50&s1=5,297,284.WKU.&OS=PN/5,297,284&RS=PN/ 5,297,284 > > [ US Patent Number: 5,297,284] > >> That would make it impossible for gcc >> to emulate it, unless Microsoft gave explicit permission Don't be too quick to make legal conclusions of this type unless you have a basis for doing so. I certainly see no basis for such a conclusion from what I have seen. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 22:21 ` Ian Lance Taylor 2004-01-30 22:52 ` Devang Patel @ 2004-01-30 23:25 ` Edward S. Peschko 2004-01-31 20:18 ` Oscar Fuentes 2004-01-30 23:55 ` tm_gccmail 2 siblings, 1 reply; 22+ messages in thread From: Edward S. Peschko @ 2004-01-30 23:25 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gcc On Fri, Jan 30, 2004 at 04:49:03PM -0500, Ian Lance Taylor wrote: > "Edward S. Peschko" <esp5@pge.com> writes: > > > > BTW, FYI, Borland is not C++ ABI compatible with MSVC++. > > > > reference? I see different. > > > > http://shop.store.yahoo.com/1-software-group/borcbuil50en.html > > I don't see anything there which says that the C++ ABI is the same. > But I really have no information on the topic. It comes under the heading of "Microsoft Visual C++ project 6 support". They don't specifically mention ABI compatibility, but they mention that you can import Microsoft visual C++ projects into Borland, and to link to VC++ dlls through an import mechanism. In any case, operationally you've been able to link Microsoft dll's to Borland apps for years. Eg, the following discussion on google (1998): http://makeashorterlink.com/?X1B225047 > > On the other hand, I've heard several times that Microsoft has > patented their vtable layout. That would make it impossible for gcc > to emulate it, unless Microsoft gave explicit permission. > > Ian yeah. patents. you just have to look for chinks in their armor. Right now, I'm looking at the patent 5,481,708, which is a 'system and methods for optimizing object-oriented compilations', and I assume is the patent that you are talking about. http://makeashorterlink.com/?J28511047 The most pertinent claim is #1: 1. In a system for generating code executable by a computer from object-oriented source listings, said source listings including definition of classes of objects having data members and functions operative on said data members, the computer including a memory stack for creating automatic variables, a method for passing of objects by value to a function, the method comprising: a) identifying by the system a class argument being passed by value as a parameter to a particular function, said class argument comprising an object to be instantiated from a particular class; b) creating a surrogate variable for the class argument by allocating space on the memory stack for storing said value; and c) determining an address of said surrogate variable on the memory stack when code referencing said class argument is generated. Hmm. My attention is immediatly drawn to the phrase: 'In a system for generating code executable by a computer from object-oriented source listings' well, what I'm not talking about a system for genrating code executable by a computer from object oriented source listings, I'm talking about a system that *reads* an executable format. No source or compilation involved. In other words, from what I read it would be verboten for g++ to *produce* a format that is compatible with vc++. Which is fine - I really couldn't care less if g++ produces dlls that vc++ can read - all I care is that g++ can read dlls that vc++ produces. Quite ironic really - by patenting the process they insure that other compiler vendors can be compatible *with* them, but that other compiler vendors can't produce compatible dlls; probably much more of a benefit to them than whatever small speed increase this optimisation gives them. Anyways, that's the way I read it. Any other interpretations or patents? Ed ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 23:25 ` Edward S. Peschko @ 2004-01-31 20:18 ` Oscar Fuentes 0 siblings, 0 replies; 22+ messages in thread From: Oscar Fuentes @ 2004-01-31 20:18 UTC (permalink / raw) To: gcc "Edward S. Peschko" <esp5@pge.com> writes: > On Fri, Jan 30, 2004 at 04:49:03PM -0500, Ian Lance Taylor wrote: >> "Edward S. Peschko" <esp5@pge.com> writes: >> >> > > BTW, FYI, Borland is not C++ ABI compatible with MSVC++. >> > >> > reference? I see different. >> > >> > http://shop.store.yahoo.com/1-software-group/borcbuil50en.html >> >> I don't see anything there which says that the C++ ABI is the same. >> But I really have no information on the topic. > > It comes under the heading of "Microsoft Visual C++ project 6 > support". They don't specifically mention ABI compatibility, but > they mention that you can import Microsoft visual C++ projects into > Borland, This is about source code projects. > and to link to VC++ dlls through an import mechanism. Only C dll's. Not C++. The same as MinGW. > In any case, operationally you've been able to link Microsoft dll's to Borland > apps for years. Eg, the following discussion on google (1998): > > http://makeashorterlink.com/?X1B225047 That's a C newsgroup. I was a Borland C++ developer for 10 years. I *know* that Borland uses a different C++ ABI. You can do a google search, request a confirmation on the Borland newsgroups or simply try it yourself. The fact is that gcc is *not* the only Windows compiler incompatible with the MS C++ ABI. >> On the other hand, I've heard several times that Microsoft has >> patented their vtable layout. That would make it impossible for gcc >> to emulate it, unless Microsoft gave explicit permission. > > yeah. patents. you just have to look for chinks in their armor. > > Right now, I'm looking at the patent 5,481,708, which is a > 'system and methods for optimizing object-oriented compilations', and > I assume is the patent that you are talking about. > > http://makeashorterlink.com/?J28511047 > > The most pertinent claim is #1: [snip] > Anyways, that's the way I read it. Any other interpretations or patents? IMHO, it's best to ask about this to a lawyer. Coming back on-topic (for this ml) the SC has no power for adding your feature to GCC (not any other feature, BTW). You need to convince a GCC contributor to do the work (or do it yourself). -- Oscar ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 22:21 ` Ian Lance Taylor 2004-01-30 22:52 ` Devang Patel 2004-01-30 23:25 ` Edward S. Peschko @ 2004-01-30 23:55 ` tm_gccmail 2 siblings, 0 replies; 22+ messages in thread From: tm_gccmail @ 2004-01-30 23:55 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Edward S. Peschko, Oscar Fuentes, gcc On 30 Jan 2004, Ian Lance Taylor wrote: > "Edward S. Peschko" <esp5@pge.com> writes: > > > > BTW, FYI, Borland is not C++ ABI compatible with MSVC++. > > > > reference? I see different. > > > > http://shop.store.yahoo.com/1-software-group/borcbuil50en.html > > I don't see anything there which says that the C++ ABI is the same. > But I really have no information on the topic. > > On the other hand, I've heard several times that Microsoft has > patented their vtable layout. That would make it impossible for gcc > to emulate it, unless Microsoft gave explicit permission. > > Ian For more information, see this message: http://www.cygwin.com/ml/cygwin/2002-02/msg00290.html Toshi ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 21:40 ` Edward S. Peschko 2004-01-30 22:21 ` Ian Lance Taylor @ 2004-02-01 14:43 ` Kai Henningsen 2004-02-02 19:57 ` Edward S. Peschko 1 sibling, 1 reply; 22+ messages in thread From: Kai Henningsen @ 2004-02-01 14:43 UTC (permalink / raw) To: gcc esp5@pge.com (Edward S. Peschko) wrote on 30.01.04 in <20040130211615.GA16722@mdssdev05.comp.pge.com>: > On Fri, Jan 30, 2004 at 06:29:13PM +0100, Oscar Fuentes wrote: > > "Edward S. Peschko" <esp5@pge.com> writes: > > > > > Ok, I wasn't being specific enough. That is exactly what I want - > > > visual C++ ABI compatibility at the 'high level' on win32. > > > In a capsule, my argument is that it opens up a world of possibility for > > > gcc/g++ on win32, it is completely feasible through open watcom. > > > > How lack of MSVC++ ABI compatibility is hurting you? > > well it is hurting me.. Here's an example - > > Right now, the perl world on win32 is pretty much divided in half, with > the cygwin perl on the one hand, and the activestate perl on the other. > python is the same way. The question is of course, _why_ is it split like this? I do _not_ believe that C++ binary compatibility is the reason. The vast majority of Perl native-code modules is written in C, not C++, and there is no ABI incompatibility with C. In fact, I'm using DLLs from gcc- compiled code (specifically, a Linux-hosted MinGW cross-compiler - it turns out much easier to deal with cross issues than with Windows issues for tools and makefiles for my case) and have not ever had an ABI compatibility problem, because most DLLs still have C-based interfaces. (That may change, of course.) Instead, I believe the reason is Unix compatibility - or in other words, linking with CYGWIN1.DLL as opposed to MSVCRT.DLL or one of the other VC++ libc implementations. (Nota bene that MinGW gcc does link with VC++ libc implementations - that's pretty much how it is defined to work!) There are Perl modules that really want to run on some kind of Unix, and those probably prefer Cygwin. In fact, Perl itself prefers Cygwin (where fork() works) to dealing with Windows (where fork() needs to be simulated - which is of course how Cygwin manages to present a working fork()). I do not know Python, but I expect it is the same. > Hence, in order to do what I need to do, I need to maintain *two sets* of > perls and pythons. And some modules work on activestate's, some modules work > on cygwin. True, but the cause is most likely not what you believe it is - you're barking up the wrong tree. > but that's just it. How many times have you had to link to proprietary > APIs like winrunner and oracle app-works, or to control apps like photoshop? How many such APIs involve C++ as opposed to C? > No offense intended, but as it is, for large software vendors gcc is really > just a toy on win32 - it fits into its own little world, it might be nice > to play with, but I don't see any large companies releasing APIs targetted > at gcc/g++. Nor do I see them releasing APIs incompatible with gcc/g++. (Not the least because that would make them incompatible with lots of other compilers as well.) MfG Kai ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-02-01 14:43 ` Kai Henningsen @ 2004-02-02 19:57 ` Edward S. Peschko 0 siblings, 0 replies; 22+ messages in thread From: Edward S. Peschko @ 2004-02-02 19:57 UTC (permalink / raw) To: Kai Henningsen; +Cc: gcc On Sun, Feb 01, 2004 at 01:58:00PM +0200, Kai Henningsen wrote: > esp5@pge.com (Edward S. Peschko) wrote on 30.01.04 in <20040130211615.GA16722@mdssdev05.comp.pge.com>: > > > Right now, the perl world on win32 is pretty much divided in half, with > > the cygwin perl on the one hand, and the activestate perl on the other. > > python is the same way. > > The question is of course, _why_ is it split like this? > > I do _not_ believe that C++ binary compatibility is the reason. The vast > majority of Perl native-code modules is written in C, not C++, and there > is no ABI incompatibility with C. In fact, I'm using DLLs from gcc- > compiled code (specifically, a Linux-hosted MinGW cross-compiler - it > turns out much easier to deal with cross issues than with Windows issues > for tools and makefiles for my case) and have not ever had an ABI > compatibility problem, because most DLLs still have C-based interfaces. > (That may change, of course.) Well, it goes deeper than that - most developers use Visual C++ as their front-end, especially for GUI-driven apps. They use VC++-isms in their code and VC++ objects because that's what the activestate folks have compiled perl with - VC++. Hence, 50 or so win32 modules that use c++ 'by default' because the vc++ IDE makes vc++ constructs. But you are right, the msvcrt.dll vs. cygwin1.dll is an issue that's just as large (or larger). I've got some ideas on how to link with both. And then find a way to overcome the VC++ ABI compatibility. Anyways, I've been looking at that patent, and I think that it isn't that big a deal. Its fairly narrow, it doesn't cover any of the difficult stuff like RTTI, and - best yet - it looks like a patent that primarily pertains to generating a vtable, not reading it. In particular, I don't think it would be infringing on the patent if a utility was built to read the vtable format, and to *write out* a vtable format that is compatible with g++. To make it unproprietary. The first claim is the most important, and I think that this step: e) overriding the pointer to the virtual function in the virtual function table associated with the designated base class with a pointer to the compiled overriding virtual function. is especially vulnerable because any reverse engineering that g++/gcc would do would be not be performing this step, and if anything performing this step in reverse. Claims 2-14 are pretty much variations on claim 1; claims 15 - 18 cover runtime access of the vtable (which any conversion utility would overstep) and claim #19 goes back to a variation of claim 1 for good measure. That's the way I see it at least. Perhaps gcc/g++ could follow Borland's footsteps with cofftoomf.exe, start a new project and make a translation utility. That way, the core g++/gcc would be safe, and the new utility would interface with gcc.. Ed ( ps - oscar, you are right... borland does not link with c++ dlls, at least as far as I can see. I still think it would be worthwhile to do so. ) ( pps - the way I was thinking of doing the cygwin/mingw merge was to prefix all of the cygwin function calls with 'cygwin_', and to link with both msvcrt.dll and cygwin.dll at the same time. How feasible is this? ) ( ppps - are the cygwin/mingw patches 'fully integrated' into the mainline? Or are there outstanding patches? ) ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-29 23:51 ` DJ Delorie 2004-01-30 0:29 ` Edward S. Peschko @ 2004-01-30 0:37 ` Jonathan Wilson 2004-02-05 2:28 ` Christopher Faylor 1 sibling, 1 reply; 22+ messages in thread From: Jonathan Wilson @ 2004-01-30 0:37 UTC (permalink / raw) Cc: gcc > At this point, you've left the realm of gcc and wandered into either > the binutils realm, or the cygwin realm. The mechanisms for producing > DLLs are in binutils (specifically, the linker "ld"), and the policy > for making cygwin1.dll specifically rests with the cygwin project. Actually, I believe that the windows versions of GCC can already produce windows compatible DLLs. What this guy (and possibly others here and on the mingw list) seem to be asking for is for GCC to implement the visual C++ ABI (something which, from what I understand Open Watcom already does). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-30 0:37 ` Jonathan Wilson @ 2004-02-05 2:28 ` Christopher Faylor 0 siblings, 0 replies; 22+ messages in thread From: Christopher Faylor @ 2004-02-05 2:28 UTC (permalink / raw) To: Jonathan Wilson; +Cc: gcc On Fri, Jan 30, 2004 at 08:29:00AM +0800, Jonathan Wilson wrote: >>At this point, you've left the realm of gcc and wandered into either >>the binutils realm, or the cygwin realm. The mechanisms for producing >>DLLs are in binutils (specifically, the linker "ld"), and the policy >>for making cygwin1.dll specifically rests with the cygwin project. >Actually, I believe that the windows versions of GCC can already produce >windows compatible DLLs. Yes, of course it does. What other kind of DLL would a windows GCC produce besides windows compatible DLLs? cgf ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: open watcom compiling gcc on win32 2004-01-29 23:32 ` Edward S. Peschko 2004-01-29 23:51 ` DJ Delorie @ 2004-01-30 0:26 ` Jonathan Wilson 1 sibling, 0 replies; 22+ messages in thread From: Jonathan Wilson @ 2004-01-30 0:26 UTC (permalink / raw) To: Edward S. Peschko, gcc I believe what you are asking for is support for the visual C++ ABI in GCC. Not that I know much about GCC but from what I have heard, there are things in GCC that make it harder to implement and things in Open Watcom that make it easier to implement. Just as an aside, I was trying to add Thread Local Storage (i.e. the __thread keyword from visual C++) to GCC and I was unable to implement it because I was unable to figure out the correct RTL and other code to add. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-02-05 2:28 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-27 8:02 open watcom compiling gcc on win32 Edward S. Peschko 2004-01-27 8:53 ` Marcel Cox 2004-01-27 18:38 ` Edward S. Peschko 2004-01-28 20:29 ` Marcel Cox 2004-01-29 23:32 ` Edward S. Peschko 2004-01-29 23:51 ` DJ Delorie 2004-01-30 0:29 ` Edward S. Peschko 2004-01-30 0:45 ` DJ Delorie 2004-01-30 1:20 ` Edward S. Peschko 2004-01-30 17:41 ` Oscar Fuentes 2004-01-30 21:40 ` Edward S. Peschko 2004-01-30 22:21 ` Ian Lance Taylor 2004-01-30 22:52 ` Devang Patel 2004-01-30 22:53 ` Robert Dewar 2004-01-30 23:25 ` Edward S. Peschko 2004-01-31 20:18 ` Oscar Fuentes 2004-01-30 23:55 ` tm_gccmail 2004-02-01 14:43 ` Kai Henningsen 2004-02-02 19:57 ` Edward S. Peschko 2004-01-30 0:37 ` Jonathan Wilson 2004-02-05 2:28 ` Christopher Faylor 2004-01-30 0:26 ` Jonathan Wilson
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).