* Cross Compiler Unix - Windows @ 2005-08-26 0:09 Ivan Novick 2005-08-26 0:49 ` Mike Stump 2005-08-29 15:14 ` Andy Smith 0 siblings, 2 replies; 23+ messages in thread From: Ivan Novick @ 2005-08-26 0:09 UTC (permalink / raw) To: gcc-help, gcc Can you recommend a solution for compiling Windows DLLs on any variation of UNIX? We currently do this with Cygwin/Windows, but would like to go one step further and do the builds on a UNIX machine that produces Windows DLLs. Thanks for any advice, Ivan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 0:09 Cross Compiler Unix - Windows Ivan Novick @ 2005-08-26 0:49 ` Mike Stump 2005-08-26 0:53 ` Ivan Novick 2005-08-29 15:14 ` Andy Smith 1 sibling, 1 reply; 23+ messages in thread From: Mike Stump @ 2005-08-26 0:49 UTC (permalink / raw) To: Ivan Novick; +Cc: gcc-help, gcc On Aug 25, 2005, at 5:09 PM, Ivan Novick wrote: > Can you recommend a solution for compiling Windows DLLs on any > variation of UNIX? Yes, just use cygwin, see the cygwin folks for details. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 0:49 ` Mike Stump @ 2005-08-26 0:53 ` Ivan Novick 2005-08-26 1:01 ` Eric Christopher 2005-08-26 1:08 ` Mike Stump 0 siblings, 2 replies; 23+ messages in thread From: Ivan Novick @ 2005-08-26 0:53 UTC (permalink / raw) To: Mike Stump; +Cc: Ivan Novick, gcc-help, gcc Yes understood, but thats the whole point, cygwin runs on a windows machine... I would like to use a UNIX machine to compile the Windows DLL. From a system admin point of view, we would like to have a UNIX compile host to produce the DLL, since we primarily only deal with UNIX anyway. Having a windows machine with an ssh server running as a compile host is less favorable than a UNIX machine with a cross compiler. Ivan On 26 Aug 2005, at 01:48, Mike Stump wrote: > On Aug 25, 2005, at 5:09 PM, Ivan Novick wrote: > >> Can you recommend a solution for compiling Windows DLLs on any >> variation of UNIX? >> > > Yes, just use cygwin, see the cygwin folks for details. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 0:53 ` Ivan Novick @ 2005-08-26 1:01 ` Eric Christopher 2005-08-26 1:08 ` Mike Stump 1 sibling, 0 replies; 23+ messages in thread From: Eric Christopher @ 2005-08-26 1:01 UTC (permalink / raw) To: Ivan Novick; +Cc: Mike Stump, gcc-help, gcc On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote: > Yes understood, but thats the whole point, cygwin runs on a windows > machine... I would like to use a UNIX machine to compile the > Windows DLL. You can cross compile to cygwin using gcc. An old link from google with "cross compiler cygwin" is available here: http://www.delorie.com/howto/cygwin/cygwin-cross-howto.html -eric ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 0:53 ` Ivan Novick 2005-08-26 1:01 ` Eric Christopher @ 2005-08-26 1:08 ` Mike Stump 2005-08-26 7:56 ` Kai Ruottu 1 sibling, 1 reply; 23+ messages in thread From: Mike Stump @ 2005-08-26 1:08 UTC (permalink / raw) To: Ivan Novick; +Cc: gcc-help, gcc On Aug 25, 2005, at 5:53 PM, Ivan Novick wrote: > Yes understood, but thats the whole point, cygwin runs on a windows > machine... Odd, I was running it on a solaris machine not windows. Maybe you forgot to recompile it on a UNIX machine? configure --with-headers=/cygwin/usr/include --with-libs=/cygwin/usr/ lib target=i386-pc-cygwin && make && make install would be an example of how I used to build one up, see the gcc documentation for details. --with-sysroot or some such might be another way to to do it now-a-days. > I would like to use a UNIX machine to compile the Windows DLL. Yes. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 1:08 ` Mike Stump @ 2005-08-26 7:56 ` Kai Ruottu 2005-08-26 16:48 ` Mike Stump ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Kai Ruottu @ 2005-08-26 7:56 UTC (permalink / raw) To: gcc-help; +Cc: gcc Mike Stump wrote: > configure --with-headers=/cygwin/usr/include --with-libs=/cygwin/usr/ > lib target=i386-pc-cygwin && make && make install > > would be an example of how I used to build one up, see the gcc > documentation for details. --with-sysroot or some such might be > another way to to do it now-a-days. That the 'native' Cygwin GCC mimics some unexisting proprietary native 'cc' in its headers and libraries directories instead of just being only another "C/C++/Java/Fortran/..." compiler set on Windoze, like those GCCs for 'h8300-*', 'sh-*, 'arm-*' etc. GCCs without any GCCs on their 'native' area, has always been very weird... The same thing happens with the 'official' MinGW GCC, it too tries to mimic some still unknown native 'cc' ! Not even mentioning Linux and its GCC idea: "There can be only one!", seemingly borrowed from the "Highlander" -- that all the GCCs on a host system should use a common $prefix has seemingly been totally unknown by the Linux people and they really expected the native GCC to be the only GCC ever on that host! Or that if one needs more GCCs, they can only be other versions for the native GCC... Platforms like Solarises, AIXes, HP-UXes, Irixes, SVR[3-5],... really have their proprietary native 'cc's which GCC has some sane reasons to mimic and so try to access their installed headers and libraries from their original places. But the native-GCC will be installed into some 'local' or 'options' place, '/usr/local', '/opt/gcc' or something, where one can add as many other GCCs as one wishes. Not to the '/usr' as has been the rule on those "no native 'cc' seen ever here" platforms. Is there any sane reasons for this on systems which never have had that non-GNU native 'cc' ? The '--with-sysroot' tries to keep the 'proprietary' layouts even on the cross-hosts, where people could always use the "standard install layout for GCC", every GCC installed using just the same rules. So the situation where all crosscompilers use their own proprietary layouts has somehow been seen being better that trying to standardize the GCC installation layout. The current cross-GCC install layout has its problems : there is only one $target dependent place for the libraries when a typical native GCC has at least two, '/lib' and '/usr/lib'. Meanwhile a cross-GCC has two places for the headers: the '$tooldir/include' for the standard (posix) headers and the '$tooldir/sys-include' for the system-specific (non-posix etc.) headers. And maybe the last 10 years or so the GCC developers have mixed these apples and oranges, standard and system things, so the cross-GCC build has been a continuous mess, target headers being searched from the 'sys-include' when the de-facto place is the 'include' (For instance the newlib install puts the target headers to the 'include' and they are there when one wants to try to build a newer GCC.) And such... If most of the native GCCs have only the '/usr/include', the STANDARD_INCLUDE_DIR, and there is no place for the SYSTEM_INCLUDE_DIR (please search the GCC manuals for this), is it so hard to leave the 'sys-include' unnoticed? However anyone who has built more than 10 GCCs for more than 10 targets and then installed them on the same development platform, has somehow got used to the current (but limiting) layout, and has solved the problems somehow. For instance what to do with the Solaris2 '/usr/lib', '/usr/ccs/lib', '/usr/ucblib', '/usr/ccs/ucblib' and so on library places someone recently had some problems with. And before the '--with-sysroot' appeared at all... Before trying to move the proprietary layouts into the peaceful? land of cross, it could have been better to ask the crosscompiler builders how they have solved these "copy the target headers and libs from the native system and put them to work with the cross-GCCs too" problems. Maybe then there had no reason for the '--with-sysroot'. Does it even work as one would expect it to work, solving those '/lib' and '/usr/lib' in the 'libc.so' script problems and so on? Ok, as long as there are those stupid installs to '/usr' on the native front, as long people must think how on earth the natively installed C libraries can be copied to the cross host. Linux is a good example about this stupidity in the very beginning. Instead of thinking how one could produce apps for Linux easily on ANY host, it was thought how one could produce apps for Linux ONLY on the Linux host and so trying to make cross-compiling to Linux as hard as possible. Not using '--with-sysroot=' at all, but simply putting the '/lib' and '/usr' stuff below a '$sysroot' and then symlinking the '$sysroot/usr/include' and '$sysroot/usr/lib' to be seen as 'include' and 'lib' on the $gcc_tooldir, adding a couple more symlinks to the 'lib' and editing the absolute paths away from the 'libc.so', enables one to get a Linux-targeted GCC to work. With 64-bit bi-arch targets one of course uses the default 'lib64' as the place here the $gcc_tooldir/lib' leads to... No need for '--with-sysroot=' with the 64-bit bi-arch targets either. "It is vain to produce anything for the idiots to follow, because idiots are so clever and always invent a better way to do just the same thing!" (Was the '--with-sysroot' made for people who are not as clever as we cross-GCC people who were considered being complete idiots? :-) What becomes to Cygwin and MinGW, the same attitude as followed with Linux, that "producing any apps for Windoze should happen only on Windoze, or that when one does it on some other host, it still should happen just like on Windoze!", is totally weird to me. My thought would be: "Producing apps for Windoze on Windoze should happen just like it happens on any other host, and at the same time quite in the same way as it happens with any other GCC which is hosted on Windoze!". ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 7:56 ` Kai Ruottu @ 2005-08-26 16:48 ` Mike Stump 2005-08-26 17:11 ` Dave Korn 2005-08-30 7:37 ` Kai Ruottu 2005-08-26 20:39 ` Nix 2005-08-27 3:05 ` Daniel Jacobowitz 2 siblings, 2 replies; 23+ messages in thread From: Mike Stump @ 2005-08-26 16:48 UTC (permalink / raw) To: karuottu; +Cc: gcc-help, gcc On Friday, August 26, 2005, at 12:59 AM, Kai Ruottu wrote: > Is there any sane reasons for this on systems which never have had that > non-GNU native 'cc' ? Consistency. This is only bad if one abhors consistency and predicability. No? I'll abstain from answering the other questions, I think they are better as ponder points. ^ permalink raw reply [flat|nested] 23+ messages in thread
* RE: Cross Compiler Unix - Windows 2005-08-26 16:48 ` Mike Stump @ 2005-08-26 17:11 ` Dave Korn 2005-08-30 7:15 ` Kai Ruottu 2005-08-30 7:37 ` Kai Ruottu 1 sibling, 1 reply; 23+ messages in thread From: Dave Korn @ 2005-08-26 17:11 UTC (permalink / raw) To: 'Mike Stump', karuottu; +Cc: gcc-help, gcc ----Original Message---- >From: Mike Stump >Sent: 26 August 2005 17:48 > On Friday, August 26, 2005, at 12:59 AM, Kai Ruottu wrote: >> Is there any sane reasons for this on systems which never have had that >> non-GNU native 'cc' ? > > Consistency. This is only bad if one abhors consistency and > predicability. No? > > I'll abstain from answering the other questions, I think they are > better as ponder points. I'll just add this observation: > What becomes to Cygwin and MinGW, the same attitude as followed with > Linux, that "producing any apps for Windoze should happen only on > Windoze, or that when one does it on some other host, it still should > happen just like on Windoze!", is totally weird to me. It seems weird to me too. Especially considering that at least one of the main cygwin developers builds everything on linux with a linux-x-windows toolchain. So perhaps you have misunderstood the situation with cygwin; cross-development is certainly possible, and _intended_ to be possible. It certainly isn't any kind of policy to _deliberately_ make development only possible on native hosts. cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 17:11 ` Dave Korn @ 2005-08-30 7:15 ` Kai Ruottu 2005-08-30 18:53 ` Mike Stump 2005-09-02 18:04 ` Christopher Faylor 0 siblings, 2 replies; 23+ messages in thread From: Kai Ruottu @ 2005-08-30 7:15 UTC (permalink / raw) To: Dave Korn; +Cc: 'Mike Stump', gcc-help, gcc Dave Korn wrote: >> What becomes to Cygwin and MinGW, the same attitude as followed with >>Linux, that "producing any apps for Windoze should happen only on >>Windoze, or that when one does it on some other host, it still should >>happen just like on Windoze!", is totally weird to me. > > It seems weird to me too. Especially considering that at least one of the > main cygwin developers builds everything on linux with a linux-x-windows > toolchain. So perhaps you have misunderstood the situation with cygwin; > cross-development is certainly possible, and _intended_ to be possible. It > certainly isn't any kind of policy to _deliberately_ make development only > possible on native hosts. Recommending Cygwin for 'ordinary users' as the preferred place for building GNU apps for Windoze, sounds weird. Just as doing the same with MinGW/MSYS. The developers can have Linuces etc. better platforms available and may require to produce everything for Linux etc. first and for Windoze too... Only building can be enough, no very hard testing or debugging in order to get the application to work is expected... This is quite the same as recommending people to build their own sport cars from Volkswagens in garages instead of doing this in car factories because only real Porches will be built in factories. People keep their self-built cars there so of course these must be built there. Or something... If one wants to produce tens of binutils, GCCs etc. GNU stuff for the Windoze host, the native Windoze shouldn't be the recommendation. Not at least when the recommendation comes from Red Hat or from any other Linux company. If Red Hat delivers the Cygwin tools for only the Windoze host, what else this is than a recommendation to use Windoze instead of their own Linux for the Windoze target development? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-30 7:15 ` Kai Ruottu @ 2005-08-30 18:53 ` Mike Stump 2005-09-02 18:04 ` Christopher Faylor 1 sibling, 0 replies; 23+ messages in thread From: Mike Stump @ 2005-08-30 18:53 UTC (permalink / raw) To: karuottu; +Cc: gcc-help You do a lot of philosophizing, this list (gcc) isn't really for that, gnu.misc.discuss is the correct place. Also, please pick just one mainline list to post to, not multiple lists. On Aug 30, 2005, at 12:19 AM, Kai Ruottu wrote: > Recommending Cygwin for 'ordinary users' as the preferred place for > building GNU apps for Windoze, sounds weird. Ordinary users don't post to gcc. gcc is the list for the development of gcc, and for power users that want to ask really obscure tricky questions. :-) If you don't like the advice, you are free to ignore it. > This is quite the same as recommending people to build their own sport > cars from Volkswagens in garages instead of doing this in car > factories > because only real Porches will be built in factories. Agreed. Welcome to the build-it-yourself, self-help group. If you want a factory show-room floor, this ain't it. My mind is so limited I just cannot grasp your point above. Is your point that you wanted us to tell you were the new car dealer is? > If one wants to produce tens of binutils, GCCs etc. GNU stuff for the > Windoze host, the native Windoze shouldn't be the recommendation. I don't recall anyone recommending a native Windows anything in this thread. > Not at least when the recommendation comes from Red Hat This list isn't for discussing what Red Hat may, or may not recommend. > or from any other Linux company. If Red Hat delivers the Cygwin > tools for only the Windoze host, what else this is than a > recommendation to use Windoze instead of their own Linux for the > Windoze target development? Reality, customer choice, free market, pick one, or two, or three. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-30 7:15 ` Kai Ruottu 2005-08-30 18:53 ` Mike Stump @ 2005-09-02 18:04 ` Christopher Faylor 2005-09-02 21:45 ` Ivan Novick 2005-09-19 13:31 ` Gerald Pfeifer 1 sibling, 2 replies; 23+ messages in thread From: Christopher Faylor @ 2005-09-02 18:04 UTC (permalink / raw) To: gcc, gcc-help On Tue, Aug 30, 2005 at 10:19:36AM +0300, Kai Ruottu wrote: >Dave Korn wrote: >>>What becomes to Cygwin and MinGW, the same attitude as followed with >>>Linux, that "producing any apps for Windoze should happen only on >>>Windoze, or that when one does it on some other host, it still should >>>happen just like on Windoze!", is totally weird to me. >> >>It seems weird to me too. Especially considering that at least one of >>the main cygwin developers builds everything on linux with a >>linux-x-windows toolchain. So perhaps you have misunderstood the >>situation with cygwin; cross-development is certainly possible, and >>_intended_ to be possible. It certainly isn't any kind of policy to >>_deliberately_ make development only possible on native hosts. > >Recommending Cygwin for 'ordinary users' as the preferred place for >building GNU apps for Windoze, sounds weird. Just as doing the same >with MinGW/MSYS. The developers can have Linuces etc. better >platforms available and may require to produce everything for Linux >etc. first and for Windoze too... Only building can be enough, no >very hard testing or debugging in order to get the application to work >is expected... So, you think that when people need to build windows apps, the "recommendation" should be that people should buy a linux box, put their sources on the linux box, figure out where to get or how to build a cross compiler, build the sources, and then figure out how to transfer the sources to the windows platform. The alternative is to install Cygwin or MSYS and then just build your sources without worrying about linux, cross compilers, or how to transfer software to/from windows. Ever heard of Occam's razor? >This is quite the same as recommending people to build their own sport >cars from Volkswagens in garages instead of doing this in car factories >because only real Porches will be built in factories. People keep >their self-built cars there so of course these must be built there. Or >something... I have no idea what this analogy is trying to say but, again, recommending to people that they go out of their way not to build on the platform that they are targetting is clearly not the most straightforward or foolproof plan. >If one wants to produce tens of binutils, GCCs etc. GNU stuff for the >Windoze host, the native Windoze shouldn't be the recommendation. Not >at least when the recommendation comes from Red Hat or from any other >Linux company. If Red Hat delivers the Cygwin tools for only the >Windoze host, what else this is than a recommendation to use Windoze >instead of their own Linux for the Windoze target development? Huh? What does "Red Hat" have to do with anything? "Red Hat" doesn't provide the tools. Cygwin is a volunteer effort. The fact that you can build cross compilers from some other system to windows doesn't mean that Cygwin is at fault for not providing the cross compilers. The whole *point* of Cygwin is to provide a linux-like environment for Windows. The fact that I do build the cygwin release on linux doesn't mean that I'd recommend doing this to every person who wants to compile stuff for Windows. -- Christopher Faylor spammer? -> aaaspam@sourceware.org Cygwin Co-Project Leader aaaspam@duffek.com TimeSys, Inc. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-09-02 18:04 ` Christopher Faylor @ 2005-09-02 21:45 ` Ivan Novick 2005-09-19 13:31 ` Gerald Pfeifer 1 sibling, 0 replies; 23+ messages in thread From: Ivan Novick @ 2005-09-02 21:45 UTC (permalink / raw) To: gcc, gcc-help > So, you think that when people need to build windows apps, the > "recommendation" should be that people should buy a linux box, put > their > sources on the linux box, figure out where to get or how to build a > cross compiler, build the sources, and then figure out how to transfer > the sources to the windows platform. > > The alternative is to install Cygwin or MSYS and then just build your > sources without worrying about linux, cross compilers, or how to > transfer > software to/from windows. > As the person who started this thread over 2 weeks ago, hopefully the thread can end here... The original question was asked because we are mostly a UNIX house and want to use Windows as little as possible... Hence the question "is it possible to build a Windows DLL without Windows at all" ... We currently use Cygwin for this which works just fine... but from our perspective the less Windows the better ... Thanks all for the helpful replies. Ivan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-09-02 18:04 ` Christopher Faylor 2005-09-02 21:45 ` Ivan Novick @ 2005-09-19 13:31 ` Gerald Pfeifer 2005-09-19 16:09 ` Christopher Faylor 1 sibling, 1 reply; 23+ messages in thread From: Gerald Pfeifer @ 2005-09-19 13:31 UTC (permalink / raw) To: gcc; +Cc: gcc-help On Fri, 2 Sep 2005, Christopher Faylor wrote: > Huh? What does "Red Hat" have to do with anything? "Red Hat" doesn't > provide the tools. Cygwin is a volunteer effort. According to http://cygwin.com/license.html (and the link from there) Red Hat does provide tools for some set of users at least: Red Hat sells a special Cygwin License for customers who are unable to provide their application in open source code form. For more information, please see: http://www.redhat.com/software/cygwin/ Gerald ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-09-19 13:31 ` Gerald Pfeifer @ 2005-09-19 16:09 ` Christopher Faylor 0 siblings, 0 replies; 23+ messages in thread From: Christopher Faylor @ 2005-09-19 16:09 UTC (permalink / raw) To: gcc, gcc-help WHY are you resurrecting this discussion? On Mon, Sep 19, 2005 at 03:30:37PM +0200, Gerald Pfeifer wrote (after a 2+ week delay): >On Fri, 2 Sep 2005, Christopher Faylor wrote: >>Huh? What does "Red Hat" have to do with anything? "Red Hat" doesn't >>provide the tools. Cygwin is a volunteer effort. > >According to http://cygwin.com/license.html (and the link from there) >Red Hat does provide tools for some set of users at least: > >Red Hat sells a special Cygwin License for customers who are unable to >provide their application in open source code form. For more >information, please see: http://www.redhat.com/software/cygwin/ Uh, yeah. I wonder who wrote those words. Ok. Yes. Red Hat does sporadically and half-heartedly sell the Cygwin tools. However no one, prior to this had mentioned Red Hat. We're in a free-software forum which was talking about Cygwin so the correct supposition is that we're not talking to the 2 Red Hat Cygwin customers here. We're talking to people who have accessed Cygwin via the cygwin.com web site. That site is maintained by volunteers (mainly me). The software is provided free of charge from the cygwin site, not by Red Hat, like any other free software project out there. Conflating Red Hat policy with the free software distribution used by 99.9999999999% of cygwin users is not useful. cgf ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 16:48 ` Mike Stump 2005-08-26 17:11 ` Dave Korn @ 2005-08-30 7:37 ` Kai Ruottu 2005-08-30 18:58 ` Mike Stump 1 sibling, 1 reply; 23+ messages in thread From: Kai Ruottu @ 2005-08-30 7:37 UTC (permalink / raw) To: Mike Stump; +Cc: gcc-help, gcc Mike Stump wrote: > On Friday, August 26, 2005, at 12:59 AM, Kai Ruottu wrote: > >> Is there any sane reasons for this on systems which never have had that >> non-GNU native 'cc' ? > > Consistency. This is only bad if one abhors consistency and > predicability. No? I understand people coming from all kind of native cultures and so the unified 'one culture' world seen with cross-GCCs, sounds strange. For me the cross world is the familiar and all those native worlds are the strange ones... A better approach could have been to think with every $target, how on earth those proprietary headers & libraries could be installed into the "standard GCC" install layout. Linux could have served as the example for the standard GCC just as well as those GCCs which produce stuff for Windoze. All the complaints about apps requiring them being built natively, not by cross-compiling them, could have been rare. If GCC would have had its standard search places and the stuff in these found automatically, no need to put any -I/usr/X11R6/include -L/usr/X11R6/lib like options into the GCC command line in the sources when compiling them with GCC would have been necessary. The need for these seemingly comes from the need to use those proprietary 'cc's to produce the same sources. Ok, I don't even remember when I have needed the original native GCCs for any builds. Maybe my repertoire is seriously limited nowadays, only GCCs, binutils, GDB/Insights and glibcs/newlibs... If requiring to build bash, tcsh etc. shells, whole Linux distros, maybe I would meet the problems. But were the problems there already or has the "native only" attitude caused them? What if crosscompiling had been the default everywhere? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-30 7:37 ` Kai Ruottu @ 2005-08-30 18:58 ` Mike Stump 2005-09-02 17:53 ` Christopher Faylor 0 siblings, 1 reply; 23+ messages in thread From: Mike Stump @ 2005-08-30 18:58 UTC (permalink / raw) To: karuottu; +Cc: gcc-help On Aug 30, 2005, at 12:42 AM, Kai Ruottu wrote: > I understand people coming from all kind of native cultures and > so the unified 'one culture' world seen with cross-GCCs, sounds > strange. For me the cross world is the familiar Apparently not, as you didn't just build up a compiler and use it. > and all those native worlds are the strange ones... You seem awfully hung up on native cygwin, a topic no one but you even mentioned. Why did you bring it up? > A better approach could have been to think with every $target, how > on earth those proprietary headers & libraries could be installed > into the "standard GCC" install layout. We welcome your patch to implement this. > All the complaints about apps requiring them being built natively, > not by cross-compiling them, could have been rare. We welcome your patch to fix this. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-30 18:58 ` Mike Stump @ 2005-09-02 17:53 ` Christopher Faylor 0 siblings, 0 replies; 23+ messages in thread From: Christopher Faylor @ 2005-09-02 17:53 UTC (permalink / raw) To: karuottu, Mike Stump, gcc-help On Tue, Aug 30, 2005 at 11:58:24AM -0700, Mike Stump wrote: >On Aug 30, 2005, at 12:42 AM, Kai Ruottu wrote: >> I understand people coming from all kind of native cultures and >>so the unified 'one culture' world seen with cross-GCCs, sounds >>strange. For me the cross world is the familiar > >Apparently not, as you didn't just build up a compiler and use it. > >>and all those native worlds are the strange ones... > >You seem awfully hung up on native cygwin, a topic no one but you >even mentioned. Why did you bring it up? Yeah, and it's native cygwin which has a layout which tries very hard to mimic a standard UNIX layout for what should be extremely obvious reasons. cgf ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 7:56 ` Kai Ruottu 2005-08-26 16:48 ` Mike Stump @ 2005-08-26 20:39 ` Nix 2005-08-29 20:02 ` Gerald Pfeifer 2005-08-27 3:05 ` Daniel Jacobowitz 2 siblings, 1 reply; 23+ messages in thread From: Nix @ 2005-08-26 20:39 UTC (permalink / raw) To: karuottu; +Cc: gcc-help, gcc On 26 Aug 2005, Kai Ruottu complained: > Not even mentioning Linux and its GCC idea: "There can > be only one!", seemingly borrowed from the "Highlander" -- that all the > GCCs on a host system should use a common $prefix has seemingly been > totally unknown by the Linux people and they really expected the native > GCC to be the only GCC ever on that host! Or that if one needs more > GCCs, they can only be other versions for the native GCC... This is nonsense. I have a dozen cross-compilers on this box, all installed into /usr. They do not collide as long as you configure with --enable-version-specific-runtime-libs and --program-{prefix,suffix,transform-name} and make slight adjustments after installation (ditch libiberty.a and some locale and manpage stuff that doesn't get its name suitably adjusted). There is nothing whatsoever special about the system compiler on Linux. It's just a GCC configured with particular switches, that is all. > The '--with-sysroot' tries to keep the 'proprietary' layouts even on > the cross-hosts, where people could always use the "standard install > layout for GCC", every GCC installed using just the same rules. So the > situation where all crosscompilers use their own proprietary layouts > has somehow been seen being better that trying to standardize the GCC > installation layout. Er, GCC will always look in ${tooldir}/lib for libraries, ${tooldir)/bin for binaries, and so on. (Your comments below indicate that you know this: so what are you talking about here?) > The current cross-GCC install layout has its problems : there is only > one $target dependent place for the libraries when a typical native GCC > has at least two, '/lib' and '/usr/lib'. If you are installing libgcc_s.so* into /lib, you'd better damned well know what you're doing, as you'll be overwriting the distribution's copy. Doing it automatically strikes me as a seriously bad idea: anyone installing an old GCC in parallel with a new one would stand at risk of wrecking every program on their system dynamically linked against libgcc_s. (Those of us who don't use distributions generally have installation-time scripts that can do the necessary by-hand mv.) There were huge flamewars^W^Wintense debates about this when libgcc was made into a shared library: look at the list archives. > Meanwhile a cross-GCC has two > places for the headers: the '$tooldir/include' for the standard (posix) > headers and the '$tooldir/sys-include' for the system-specific > (non-posix etc.) headers. Personally I've never quite seen the point of sys-lib and sys-include. I just dump all the target libraries and headers into the target- specific lib and include directories. :) > However anyone who has built more than 10 GCCs for more than 10 targets > and then installed them on the same development platform, has somehow > got used to the current (but limiting) layout, and has solved the > problems somehow. For instance what to do with the Solaris2 '/usr/lib', > '/usr/ccs/lib', '/usr/ucblib', '/usr/ccs/ucblib' and so on library > places someone recently had some problems with. I created ${tooldir}/ccs/lib et al and just had a site-config script construct suitable -L arguments to GCC. (If you're doing much cross-compilation you'll end up with a site-config script full of all sorts of stuff anyway. This is nothing by comparison.) > Ok, as long as there are those stupid installs to '/usr' on the native > front, as long people must think how on earth the natively installed > C libraries can be copied to the cross host. Er, NFS? cp? tar? All of them work. > Linux is a good example > about this stupidity in the very beginning. Instead of thinking how > one could produce apps for Linux easily on ANY host, it was thought > how one could produce apps for Linux ONLY on the Linux host and so > trying to make cross-compiling to Linux as hard as possible. It's not hard. Just lump everything in /lib into the same place as everything in /usr/lib on the compilation host, and everything will work fine. > Not using '--with-sysroot=' at all, but simply putting the '/lib' > and '/usr' stuff below a '$sysroot' and then symlinking the > '$sysroot/usr/include' and '$sysroot/usr/lib' to be seen as 'include' > and 'lib' on the $gcc_tooldir, adding a couple more symlinks to the > 'lib' and editing the absolute paths away from the 'libc.so', enables > one to get a Linux-targeted GCC to work. Indeed it does. (The libc.so absolute paths are... silly, but that's not something you can blame on GCC. Best of luck convincing Ulrich to change it.) > With 64-bit bi-arch targets > one of course uses the default 'lib64' as the place here the > $gcc_tooldir/lib' leads to... No need for '--with-sysroot=' with the > 64-bit bi-arch targets either. Yeah, but they're not really cross-compilers in that sense: they're native compilers with extra magic (hardwired into the appropriate backend code, no less; somewhat icky, I feel, but I can't think of a better way to do it myself: unlike binutils, GCC just doesn't have the generic infrastructure for multiple-simultaneous-target support, and until *everything* is hookized is unlikely to. I imagine hookizing everything would have another negative impact on compilation speed, which is hardly a good thing.) I'm not sure what you're complaining about here: your English is just fractured enough to impair my comprehension. Is it --with-sysroot you dislike (in which case, ditto: what's it meant for?), or is it installing multiple parallel compilers in /usr (which works just fine) or what? -- `... published last year in a limited edition... In one of the great tragedies of publishing, it was not a limited enough edition and so I have read it.' --- James Nicoll ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 20:39 ` Nix @ 2005-08-29 20:02 ` Gerald Pfeifer 2005-08-30 16:24 ` Nix 0 siblings, 1 reply; 23+ messages in thread From: Gerald Pfeifer @ 2005-08-29 20:02 UTC (permalink / raw) To: Nix; +Cc: karuottu, gcc-help, gcc On Fri, 26 Aug 2005, Nix wrote: > This is nonsense. I have a dozen cross-compilers on this box, all > installed into /usr. They do not collide as long as you configure with > --enable-version-specific-runtime-libs and > --program-{prefix,suffix,transform-name} and make slight adjustments > after installation (ditch libiberty.a and some locale and manpage stuff > that doesn't get its name suitably adjusted). mudflap is an offender as well, see Bugzilla #18244 (libmudflap installs include/mf-runtime.h in version-independent path). Java has libdata/pkgconfig/libgcj.pc and include/ffi.h. And, like the man pages, the info files do not honor --program-suffix, but for regular C, C++, Objective-C and Fortran development neither of is a real killer, agreed. Gerald ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-29 20:02 ` Gerald Pfeifer @ 2005-08-30 16:24 ` Nix 2005-09-17 22:53 ` Gerald Pfeifer 0 siblings, 1 reply; 23+ messages in thread From: Nix @ 2005-08-30 16:24 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: karuottu, gcc-help, gcc On 29 Aug 2005, Gerald Pfeifer said: > On Fri, 26 Aug 2005, Nix wrote: >> --enable-version-specific-runtime-libs and >> --program-{prefix,suffix,transform-name} and make slight adjustments >> after installation (ditch libiberty.a and some locale and manpage stuff >> that doesn't get its name suitably adjusted). > > mudflap is an offender as well, see Bugzilla #18244 (libmudflap > installs include/mf-runtime.h in version-independent path). > > Java has libdata/pkgconfig/libgcj.pc and include/ffi.h. > > And, like the man pages, the info files do not honor --program-suffix, > but for regular C, C++, Objective-C and Fortran development neither of > is a real killer, agreed. Well, the man and info pages are always the same (assuming you're installing the same GCC release targetted differently), so there's no real problem there. The same seems to be true of libgcj.pc and mf-runtime.h. The ffi.h thing really is a bug with consequences: the thing's got target-dependent contents :/ -- `... published last year in a limited edition... In one of the great tragedies of publishing, it was not a limited enough edition and so I have read it.' --- James Nicoll ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-30 16:24 ` Nix @ 2005-09-17 22:53 ` Gerald Pfeifer 0 siblings, 0 replies; 23+ messages in thread From: Gerald Pfeifer @ 2005-09-17 22:53 UTC (permalink / raw) To: Nix; +Cc: karuottu, gcc-help, gcc On Tue, 30 Aug 2005, Nix wrote: >> mudflap is an offender as well, see Bugzilla #18244 (libmudflap >> installs include/mf-runtime.h in version-independent path). >> >> Java has libdata/pkgconfig/libgcj.pc and include/ffi.h. >> >> And, like the man pages, the info files do not honor --program-suffix, >> but for regular C, C++, Objective-C and Fortran development neither of >> is a real killer, agreed. > The ffi.h thing really is a bug with consequences: the thing's got > target-dependent contents :/ This is now Bugzilla java/23935 ($PREFIX/include/ffi.h needs to go to a target- and -version-dependent location), in case someone knowledgeable wants to have a look. Gerald ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 7:56 ` Kai Ruottu 2005-08-26 16:48 ` Mike Stump 2005-08-26 20:39 ` Nix @ 2005-08-27 3:05 ` Daniel Jacobowitz 2 siblings, 0 replies; 23+ messages in thread From: Daniel Jacobowitz @ 2005-08-27 3:05 UTC (permalink / raw) To: Kai Ruottu; +Cc: gcc-help, gcc Most of this really doesn't deserve an answerr, but I'll give you a couple anyway. You spend a lot of time blaming people for their opinions, without any evidence that you've actually understood their opinions right. Most of what I've snipped is completely untrue. On Fri, Aug 26, 2005 at 10:59:58AM +0300, Kai Ruottu wrote: > The '--with-sysroot' tries to keep the 'proprietary' layouts even on > the cross-hosts, where people could always use the "standard install > layout for GCC", every GCC installed using just the same rules. So the > situation where all crosscompilers use their own proprietary layouts > has somehow been seen being better that trying to standardize the GCC > installation layout. No. The point of --with-sysroot is so that you can build a native compiler for some target, and a cross compiler to that same target, and have them use the same layout. The native layout is _not_ something that we can change at this date, whatever you may like to think about it. > Before trying to move the proprietary layouts into the peaceful? > land of cross, it could have been better to ask the crosscompiler > builders how they have solved these "copy the target headers and > libs from the native system and put them to work with the cross-GCCs > too" problems. Maybe then there had no reason for the '--with-sysroot'. > Does it even work as one would expect it to work, solving those '/lib' > and '/usr/lib' in the 'libc.so' script problems and so on? Of course it does. The absolute paths will be handled correctly by ld. This was done to minimize the pain of building cross compilers to "hosted" systems. It seems to have worked, since everyone I've spoken to who's used it finds it much more natural, and the process has less undocumented voodoo than the --with-headers/--with-libs setup. > better way to do just the same thing!" (Was the '--with-sysroot' made > for people who are not as clever as we cross-GCC people who were > considered being complete idiots? :-) As one of the people who implemented this, I take offense at your comments. If you couldn't tell. -- Daniel Jacobowitz CodeSourcery, LLC ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Cross Compiler Unix - Windows 2005-08-26 0:09 Cross Compiler Unix - Windows Ivan Novick 2005-08-26 0:49 ` Mike Stump @ 2005-08-29 15:14 ` Andy Smith 1 sibling, 0 replies; 23+ messages in thread From: Andy Smith @ 2005-08-29 15:14 UTC (permalink / raw) To: Ivan Novick, gcc-help, gcc I have used MinGW on Linux to compile Windows executables. I don't see why it could not be compiled on other Unix variants. Try: http://www.libsdl.org/extras/win32/cross/README.txt and http://www.mingw.org Regards, Andy --- Ivan Novick <ivan.novick@makoglobal.com> wrote: > Can you recommend a solution for compiling Windows > DLLs on any > variation of UNIX? > > We currently do this with Cygwin/Windows, but would > like to go one > step further and do the builds on a UNIX machine > that produces > Windows DLLs. > > Thanks for any advice, > > Ivan > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2005-09-19 16:09 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-08-26 0:09 Cross Compiler Unix - Windows Ivan Novick 2005-08-26 0:49 ` Mike Stump 2005-08-26 0:53 ` Ivan Novick 2005-08-26 1:01 ` Eric Christopher 2005-08-26 1:08 ` Mike Stump 2005-08-26 7:56 ` Kai Ruottu 2005-08-26 16:48 ` Mike Stump 2005-08-26 17:11 ` Dave Korn 2005-08-30 7:15 ` Kai Ruottu 2005-08-30 18:53 ` Mike Stump 2005-09-02 18:04 ` Christopher Faylor 2005-09-02 21:45 ` Ivan Novick 2005-09-19 13:31 ` Gerald Pfeifer 2005-09-19 16:09 ` Christopher Faylor 2005-08-30 7:37 ` Kai Ruottu 2005-08-30 18:58 ` Mike Stump 2005-09-02 17:53 ` Christopher Faylor 2005-08-26 20:39 ` Nix 2005-08-29 20:02 ` Gerald Pfeifer 2005-08-30 16:24 ` Nix 2005-09-17 22:53 ` Gerald Pfeifer 2005-08-27 3:05 ` Daniel Jacobowitz 2005-08-29 15:14 ` Andy Smith
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).