Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Microsoft Software Programming Linux IT Technology

Xmingwin For Cross Generation Applications 108

An anonymous reader writes "Xmingwin makes it practical to generate Windows programs from a Linux server. This column gives a recipe for setting up Xmingwin, outlines the most important reasons for doing so and shows you how to generate executables for multiple platforms -- including Windows DLLs -- from a single Linux source."
This discussion has been archived. No new comments can be posted.

Xmingwin For Cross Generation Applications

Comments Filter:
  • ohhh maaaan (Score:5, Insightful)

    by nocomment ( 239368 ) on Monday February 03, 2003 @01:49PM (#5216211) Homepage Journal
    I've been trying to migrate people _away_ from windows, this only makes it easier for them to stay ;-)

    Of course it also help linux break into places it wasn't allowed before, so i've got to say bravo for that!
    Still, should be running BSD ;-p
    • Im not sure I agree, wine/winex helps to windows apps in Linux and helps to give Linux a higher profile. I dont think its existance stops the adoption of or the production of apps for Linux.
      I would have thought the more choice and flexibility the better.

    • I've been trying to migrate people _away_ from windows, this only makes it easier for them to stay ;-)

      On the other hand, Microsoft has done an excellent job trying to migrate developers away from Windows by creating Visual C++, the bastard son of C++. I have yet to find any features in VC++ that would make my job as a developer easier than in gcc. (Step-by-step execution built into the GUI? The few times I would actually need it, the debugger crashes before trapping anything. IDE? If you must, use KDevelop [kdevelop.org].)

      Fortunately I've only had to work with this brilliant piece of software for short (a few months) assignments.

    • I've been trying to migrate people _away_ from windows, this only makes it easier for them to stay ;-)

      I disagree. Take a longer term view. This makes it easier for them to leave Windows. Nothing happens overnight. And won't happen as quickly as I would like.

      While so much noise and attention is being focused on Linux, I think the biggest threat to Microsoft is, once again, sneaking in under the radar. (Step 1: First they ignore you.) The biggest threat: cross-over applications. Stuff like OpenOffice [openoffice.org]. Or the GIMP [gimp.org]. (And yes, I understand that GIMP is not a competitor to professional Photoshop users.)

      It seems like more and more cross platform tools and toolkits are available. This was once the holy grail, and there were basically NO solutions. Now, a recent slashdot article [slashdot.org] reveals many ways to develop cross platform applications and gui's.

      KDE and Qt are both being ported to Win32 (with GPL license). At some point, expect a flood of KDE applications, including another free KOffice suite, to be available for Windows. Other projects such as The Open CD [theopencd.org] and GNU Win II [gnuwin.epfl.ch] only help accellerate the acceptance of not only free, but open source applications by ordinary windows users.

      Eventually, users recognize: hey the OS is irrelevant!

      In the meantime, Linux on the desktop will have improved a great deal. Or instead, perhaps the recent RelaxOS [reactos.com]?
    • See it the other way. Now people who need to develop for Windows can do so on a Linux host and make their programs run in the Free World as well.
  • Testing ? (Score:4, Interesting)

    by MosesJones ( 55544 ) on Monday February 03, 2003 @01:49PM (#5216214) Homepage

    Winner of Company Most likely to produce Buggy Software....

    The people who do this. You can produce work on the Server but to properly test you still need the windows environment. So you have to deploy to that, given that you need a testing environment per developer as well as for UAT and QA then your costs aren't really reduced. The advantages in terms of compile speed are killed in terms of transfer and deployment.

    Somebody somewhere clearly things they need this, somebody somewhere doesn't work in large teams and on commercial apps.

    Sorry to dis someones work, but I'd be more interested in a decent Open Source windows IDE on windows than being able to do a fraction of the work on Linux... and I loathe MS-Windows. Why do so many Open Source projects have to ape MS rather than take on the beast.

    Too many people, too many projects. Come and save us IBM.

    • There are also cross platform virii issues too. Code being shifted around like nobodies business and things are lost track of.
      • There are also cross platform virii issues too.

        Well, isn't the mere existence of programming languages dangerous, because it lets hackers write malicious code? This sounds remotely like something **AA would say. What's more, machine code could be used as a circumvention device for copyright protection. Yes, we better outlaw binary.

        (It's called "reduction to absurdity".)

    • Re:Testing ? (Score:5, Informative)

      by catscan2000 ( 211521 ) on Monday February 03, 2003 @01:57PM (#5216264)
      If you're looking to replace Visual Studio for programs that don't rely too much on the COM wizards and such, try out Dev-C++ [bloodshed.net]. It's pretty fast, too, and it uses GCC :-).
      • Agreed. It rocks. I use both VC and Dev-c++. A Linux version is in beta and its written in kylix. I like it alot better then Eclipse.

        If you need an ide in Linux look no farther. The only issue is the beta linux version was only available on cd the last time I looked.

    • You can produce work on the Server but to properly test you still need the windows environment

      Of course you do, and I don't think the column anywhere suggested otherwise. The column is talking solely about code generation, not code testing. What this stops is having to reboot a different os, to work with the same app but in a different ide. Which means you don't have to learn 2 sets of compilers and their little idiosyncracies, maintain 2 sets of code with the hassle that entails.

      We've got maybe 250 computers in out little department, and before I deploy an app, I test on at least 3 different classes of computer. I would imaging that big companies just have a room of computers with their various base installs and various hardware classes used just for testing.

      • I would imaging that big companies just have a room of computers with their various base installs and various hardware classes used just for testing.

        Excuse me while I decide whether to laugh or cry; I work at a large corporation, on their e-commerce web site (not their main revenue stream) that does over $1 billion in revenue a year. We have no test lab. We have no test machines. We are told to test (on our own NT 4.0 machines), but not spend time on it. Sadly, I've worked in a few corporations, and they haven't been much different.
        • Re:Testing ? (Score:3, Interesting)

          by jd142 ( 129673 )
          You are right. That is sad. I'm doing an app for our students so they can sign up for job interviews via a nice little web app. Because it uses javascript, I decided to test the app on:

          --Microsoft Internet Explorer 5.5 and above on any version of Windows 9x or later
          --Mozilla 1.0 and above on Windows or Linux
          --Netscape 7.0 and above on Windows or Linux
          --Opera 6.0 on Windows
          --Konqueror 3.1 on Linux

          We don't have any macs in the building, and I just haven't gotten around to walking to one of the other buildings and checking it out. But I will before it goes live.

          During the interview season I suppose we'll get maybe 2,000 hits a week from our 750 students. But their eventual livlihood depends on their student jobs now, so this is very important to them.

          And people rag on those of us who work for the government instead of private business (which is, of course, perfectly efficient and hires only the best and brightest people).
    • Re:Testing ? (Score:3, Informative)

      by batkiwi ( 137781 )
      The number one advantage I can see for this in the environment I work in is automated builds.

      We have big linux servers that do all of our java compiling nightly (and auto-runs junit tests/etc), but you can't do that for your windows dll's without a seperate box. Now that need is gone.
      • Beyond just automated builds, my big issue with VisualStudio is that it sucks boulders through capillary tubes if you ever have to change compilation options on more than one build target, or add a bunch of "only slightly different" items to a build. Besides the fact that it's often bloody impossible to figure out where it's setting a given compiler option.

        And when I've used the VC command line tools and called up Microsoft to report bugs I've gotten laughter, at best. They simply won't support anything but the visual environment.

        This gives a full-featured development environment using real production quality tools in an environment that won't be blowing chunks every time I try to do something remotely outlandish with the USB bus. I've no problem with having a Windows box beside my Linux box for running the app, I just want a stable, full-featured development environment. Linux cross-compiling onto a Samba mount is closer to that than Microsoft's been in many years.
  • In my experience this is not what should be done.

    Moving files like this, executables which are virii prone into one system or another helps with the spread of virii. Why? It may not look logical at first

    What happens is systems that are not running the software can check it for the virii that do run on it. They'll miss the infections coming from the other platform, or perhaps some other one again.

    What you end up with is a security risk. It pulls everything down the tubes.
    • Huh? I'm not sure I understand what you're saying here, so allow me to paraphrase:

      Placing a .EXE file on a Linux server helps spread virii, because the Linux server won't check to see if the file is infected with a Windows-based virus. This is bad because if the file becomes infected, the infection will be missed.

      I'm making the generous assumption that you aren't saying that the Linus system will create an infected executable. Even so, there seem to be some unwritten assumptions here.

      First, you assume that there is an infected Windows system. Just about every commercial environment that I'm aware of runs some form of anti-virus software on every Windows-based server and desktop. This means that there is little chance of infection by a known virus. I will readily conceed that unknown infections, such as Slammer, can still be a problem, but that leads to your second assumption.

      You seem to think that any Windows-based system with read-access to the file also has write-access to it. This runs counter to the best-practices adopted at most sites. A fundimental rule of security is to provide no more access than is needed to get the job done. File servers generally restrict the average user from modifying static resources. In this case, I would include anyone with a Windows-based system as an average user. Since they aren't running a developement environment, there is no need for them to write to the directories where the software is stored.

      So, did I miss something, or did you post of subtle troll?

    • Eh? Are you moderators on crack?

      I wasn't aware that compiling a program risked creating a virus. I certainly wasn't aware that cross-compiling was so dangerous.

      I would agree with those that suggest that this doesn't seem to be a sensible way to run a production environment, but it's good for people like me, writing cross-platform applications that I will be porting to Windows. It saves me hunting down someone with the time and inclination to do my dirty work for me, as I gave up on Windows a while back now.

    • The time when viruses like Pong and Natas infected binaries are fading fast. Instead we have worms that are far more effective because they can infect other machines as opposed to just other applications on the same box. Before, you were scewed. Today, the whole goddamn Internet is screwed. It's just a matter of scale and opportunity.

      Or are you saying that Windows executables are somehow more infection prone than ELF or Mac binaries?

      It pulls everything down the tubes

      Now, now. That's just your inner zealot speaking.

      • I would say that windows executables are themselves automatically virii that need to be eradicated... you know, the usual stuff... Windows is a badly written virus (slow, bloated, writes random stuff on your hdd and crashes unexpectedly - however most viruses are compactly written works of art, so windows doesn't qualify) - however an exe binary written by a linux programmer could qualify :-P

        Daniel
        • Now, now. That's just your inner zealot speaking.
        • by Twirlip of the Mists ( 615030 ) <twirlipofthemists@yahoo.com> on Monday February 03, 2003 @04:52PM (#5217666)
          I'm on a crusade. I intend to post a comment like this one whenever I see anybody use "virii." Please don't interpret this comment as either endorsement of or disagreement with the parent post. Moderators: with your help, we can wipe out "virii" in our lifetime!

          The plural of "virus" isn't "virii." There is no such word. The plural of "virus" is "viruses."

          Here's a good explanation from cdknow.com [cknow.com], quoted here in its entirety because the people who most need to read this won't click on a link.

          The correct English plural of virus is viruses. Please consult any good dictionary before making up words.

          For the purists, in Latin, there is a rarely-used plural form:

          virus, viri (neuter)

          (Forms: almost always restricted to nominative and accusative singular; generally singular in Lucretius, ablative singular in Lucretius)

          The point of this is that even in Latin the form "viri" is rarely used. The singular form is used in most every instance. (This is from the Oxford Latin Dictionary.)

          So, when considering the Latin: "virii" is incorrect and "viri" was almost never used.

          Despite the fact there was little use for the plural form, there is another reason why "viri" was rarely used. The most common Latin word for "man" is "vir" with "viri" being its plural in the form used as the subject of a sentence. Thus, since "men" as the subject of a sentence would be used far more often than "venoms" (virus means venom) the "viri" word was most commonly seen as the plural of "man."

          Bottom line: Don't try to make up words using a false Latin plural form. Since the word virus in its English form is now used then the English plural (viruses) should be used.

          More plural-of-virus resources:

          perl.com [perl.com], the canonical and exhaustive source
          The alt.comp.virus FAQ [wisc.edu]
          Jonathan de Boyne Pollard's Frequently Given Answer [tesco.net]
          Merriam-Webster's "Word for the Wise [m-w.com]," January 20, 2000.

          • It's really sad that you spend so much time posting this comment. It has, itself, turned into a BSD is dying type troll, and yet, still, somehow, manages to get modded insightful every time.
            You know what? English has so many transliterated words that later were conjugated improperly that your fight is pointless. I mean, Cambridge and Oxford still fight over syllabuses and syllabi. Bottom line is that language changes often, and rarely follows the rules when it does. You pshawed your English teacher when she berated you about using you instead of one, and I currently bristle at the disappearance of adverbs from the language (He runs fast kills me every time). Let the language move on and evolve.
            Please stop, unless you're karma whoring, but then there's little point in that anymore, now is there? Just so you can look at percentage points?
            • I don't find it sad he spent that time. It's obviously something he feels strongly about, and if these comments always get modded up, it's clear that plenty of other people feel that way too. There's no trolling about it.
              As for virii, the word is itself a virus (or rather a worm, since it is spread by the Internet).
              Now if we're talking about evolution, let's talk about improvement through evolution rather than deterioration. Verbing nouns, for example, is now accepted because it makes certain constructions a lot more efficient. You might argue that "virii" saves two letters compared with "viruses", thus making things more efficient, but why not in that case save three letters and go for "viri" which is more logical anyway?
              Just to finish on, the word "fast" is both an adjective and an adverb (and has been since before the 12th century). Any reputable dictionary will confirm this, so you can stop bristling and live a more relaxed life.
    • Rubbish! Excluding the fact that I have seen few viruses in the last few years that weren't spread by holes email clients such as Outlook, the output of a compiler can generally be assumed to be virus free. (The exception would be for a hack similar to Ken Thompson's trojan login on the original Unix, but the chances of that working on diverse systems such as Linux and *BSD is somewhat unlikely.)

      A hacked native Windows compiler seems to me to be much more likely.

    • I think that this is incredibly unlikely to spread virus executables from one machine to another. The compiled code would not work on the machine where it was compiled. People have been doing cross-compiling for years without this problem. Virus code exploits vulnerabilities in the system - a Win32 virus will only exploit machines which supply a Win32 runtime environment.
    • I always heard Microsoft compiles on FreeBSD for their "Gold" production releases so that they don't send out programs with viruses.

    • First, I think your idea that somehow compiling on a linux box is going to create a virus or spread a win32 virus is kind of silly. The linux box does not run win32 code that is is compiling.

      Second. Sophos [sophos.com] supports (or did as of about a year ago) a linux version of their virus software. If you really needed virus scanning its there.

  • I can see it now... if this exists, somewhere in the NetBSD ports collection, it means we can actually create WinNT/Alpha applications... =)
    • Dunno if it supports WinNT/Alpha, but it should run on NetBSD - after all, it's just a slightly modified version of gcc with some supporting tools for making Windows executables.
  • Xmingwin? (Score:5, Insightful)

    by gwernol ( 167574 ) on Monday February 03, 2003 @01:56PM (#5216261)
    This sounds like intriguing functionality, but really can't they find a better name than Xmingwin? Its a horrible name, practically unpronounceable, difficult to remember and spell, easy to confuse with other similar projects.

    I know this might sound like a troll but I'm serious about this. Projects do themselves no favors by adopting badly thought out names. A confusing name makes it less likely that I will use or evangelize this software. When someone asks me for a recommendation for a software platform for generating Windows executables on our Linux servers I'll be embarassed to say Xmingwin (I work in a corporate environment). Its hard to say, hard for someone to understand when said and worse it sounds amateurish. Its almost as bad as Ogg Vorbis: very geek-cool to use Klingon but the kiss of death in a serious corporate environment.

    This isn't a slam on open source - god knows there are too many dumb names in the closed source world - but a plea for developers to think about naming. Its an important part of getting your technology talked about and accepted.
    • Re:Xmingwin? (Score:4, Insightful)

      by josh crawley ( 537561 ) on Monday February 03, 2003 @02:06PM (#5216325)
      I pronounce it like X-ming win. like ex-Penguin (with the p soundling like M)
    • It's an evolutionary thing.
      it started life as 'MinGW' which meant Minimalistic GNU for Windows.
    • This sounds like intriguing functionality, but really can't they find a better name than Xmingwin? Its a horrible name, practically unpronounceable, difficult to remember and spell, easy to confuse with other similar projects.


      You are damn right. There is no way people are going to be content with this, look at how many different variations of pronouncing leenooks there are.

      Are we going to have some more test .au's, "Hello this is and I pronounce Xmingwin, 'Bob'".
    • And PLEASE, tell me how you pronounce YOUR NAME, gwerwol?
      • And PLEASE, tell me how you pronounce YOUR NAME, gwerwol?

        Fair point - although its gwernol not gwerwol :-) Its a nickname derived from a Welsh placename, so its pretty obscure. Its actually pronounced much as its spelt: two syllables "gwer-nol".

        The real point is I'm not trying to promote my nickname. Its just a silly identifier chosen because it was available on Slashdot. Xmingwin are trying (I hope) to promote their technology and gain acceptance for it. That's why it doesn't matter that I have a stupid handle on Slashdot but it is a concern that the Xmingwin developers have a project name that might actually discourage its adoption in the broad business community.
    • from the short lived dilbert cartoon:

      PHB: "the name is the most important part of the project - I cannot stress that enough"
    • "Mozilla"

      Probably one of the most ridiculous sounding software names I've heard. Tell a manager that you're interested in using "Mozilla", and he'll tell you he's never seen that movie. Software developers, by and large, have *zero* business sense.
      • Personally, I think Mozilla is a cool name. It started as the codename of the codebase at Netscape. I've demo'd Mozilla for several people and within days they were converted. And they never once asked me, "what was the name of that program again?".

    • I am glad somebody else has noticed this. If it takes off I expect to see a Java version before too long called JXmingwin, a Python version called PXmingwin, a KDE gui version called KPXmingwin a Gnome GUI version called, guess what, GPXmingwin and perhaps the whole thing bundled into a library called libXmingwin. Before too long there will be a fork and we'll have OpenPXmingwin and FreePXmingwin. Perhaps we'll see a cywin port called cygFreeXmingwing. Eventually it will be ported to OSX where it will be called 'iWin'.

      Mind you I'll take the name cygFreeXmingwin over 'Mono' any day.

      L.

    • by dark-nl ( 568618 ) <dark@xs4all.nl> on Monday February 03, 2003 @03:19PM (#5216856)
      Every cool project should have a FAQ entry explaining its name. If the name is too easy, or has an obvious pronunciation, then it can't be a cool project. Ideally, there should be long-standing flamewars about it (i.e. is it "vee-eye" or "veye"?).
    • Anyone else read it as "X Wingman" on first glance?

      Now I can't get that pronunciation out of my head when I read the word. :P
    • From the article:
      Xmingwin is
      my label for, "Mingwin run as a cross-generating application." [emphasis added]

      As another poster has pointed out, people have been cross-compiling with MinGW (not really "Mingwin") for years, and most people seem to just call it MinGW.

      Note that Debian already comes with a MinGW cross-compiler package [debian.org], which will soon be available for non-i386 architectures [debian.org] as well (e.g. cross-compiling from ppc to win32).

    • Sounds like a perfectly good Chinese name to me...

      But then again why not just change the name to "bob", I mean please people all open source project should have should use good proper English phonemes.

      F~!@# the l18n stuff anyway...and to hell with linguistic diversity.

      I this talk has made me hungry for some good old rou-juan and potatos.
  • Usually... (Score:1, Troll)

    by termos ( 634980 )
    Usually programs like these are buggy, and it does not work 100% on both systems (look at WINE for example). Since this is not the same "idea" it could be good, but i guess it will take time before people start using it fully.
    • Re:Usually... (Score:4, Informative)

      by grolim13 ( 110441 ) on Monday February 03, 2003 @02:42PM (#5216555) Homepage
      No, you're misunderstanding how this works. Cross-compilers have been around for ages, this one just happens to have the advantage that it inherently portable (because it is based on GCC) and targets Windows (which is phenomonally popular).

      Wine works by reimplementing a part of the Windows API. Mingw32 is a compiler which takes C/C++ programs and Windows libraries and generates Windows executables. Its C/C++ support is just about flawless as it uses GCC; it can link programs against native Windows libraries just like any Windows compiler would; and it produces ordinary Windows executables.

      These Windows executables, however, won't run natively on the (Linux) host machine.

      Note that this is also not an automated system for writing portable programs; Xmingwin won't compile anything that wouldn't compile on a normal Windows machine. But if you have code that is portable, you can save a lot of hassle by having just one machine to build binaries for several platforms.

  • by ---- ( 147583 ) on Monday February 03, 2003 @02:09PM (#5216338)
    What's the difference between this announcement and the pre-existing mingw32 integration with gcc ?
    • lets see, we have ...
    • The mingw-runtime package
      The Public Domain versions of the MSVCRT header and library import files
      Beginning with version 2.0 C89 and C99 extensions are provided that include
      but not limited to, wide character functions, floating point environment
      functions (declared in fenv.h), floating point classification functions and
      macros, the inttypes.h format conversion macros, stubs for msvcrt.dll
      underscored functions that are now part of C99 standard, and a replacement for
      fseek and fwrite that are safer on W9x. The POSIX dirent functions have been
      moved from libmingw.a to libmingwex.a so those desiring 'Minimal' can easily
      have it. The ISO C extensions are visible by default within the headers, to
      remove them define __NO_ISOCEXT. You need to explicitly add these functions
      until they are eventually added to the GCC specs file for inclusion by default.
    • The gcc-mingw32 package
      Mingw32 support headers and libraries for GCC
    How exactly is this different? We've been able to produce win32 executables using mingw and gcc for years now.
  • Quick Note (Score:4, Informative)

    by jchawk ( 127686 ) on Monday February 03, 2003 @02:18PM (#5216391) Homepage Journal
    For those of you wondering, this only works for apps that you are currently writing. It isn't going to work for just any windows app, but it's still kinda neat.

    ---

    If you just signed up for a new sprint pcs cell phone I can get you a $10 rebate. Email me at jchawk@ my website (tr0n.com) that's a zero in tr0n.
  • by mlyle ( 148697 ) on Monday February 03, 2003 @02:20PM (#5216400)
    Lots of people are posting on how this is potentially a bad idea. Sure, it's not likely to be as mature as other compiler environments. There's all kinds of small shops where this could simplify build infrastructure, though. Maintaining different build servers for all the platform variation a company chooses to support can be costly to build, especially with the infrastructure to do revision control and fire off simultaneous builds and package things together. If a company just needs to produce command line tools or simple DLL's to accelerate code in a scripting language, this might be a good choice.

    Probably the largest win is allowing developers to unit test application logic on their local Windows desktop, if they prefer that environment, before doing final unit test, integration test, and deployment on top of *nix/Linux.
  • by Stiletto ( 12066 ) on Monday February 03, 2003 @02:37PM (#5216520)

    I've been using a MINGW32-based linux->win32 cross-development environment for years. The same concepts apply as for cross-compiling to different hardware architectures. This is definitely not new software. With properly written makefiles, you can build to target both Linux and Win32 platforms from the same source tree and build environment. Of course you must test on both platforms, but having a setup like this definitely makes it easier to build large projects for both Windows and Linux.
    • Preaching to the converted but thats one of the greatest assets of the make system - I'm currently working on a project using GCC/Mingw compiling with windows and I have a friend who's programming from linux with virtually no modification. Recently someone using MacOS-X joined our little group and after some tweaking they manged to get it compiling fine there as well...

      We're using SDL, OpenGL, etc and it all works great with just a ./configure, make
  • Seems like another way to get the same functionality would be to get the VC++ command-line compiler working under WINE. Has anyone had any luck with this?
    • Some people have gotten results from that, but even if it works, the result isn't really the same.

      0) VC++ is non-free. (And not just by RMS's libre definition either. Legally acquiring it can take many $$$)
      1) VC++ speaks a different dialect of C++ than gcc does. While neither of them is 100% standards compliant, you'd want the same set of workarounds to function for both target platforms.
      2) You'd need some tricky scripting to propagate error conditions from VC++ through WINE and into make's status knowledge. Connecting it to a makefile, or an Ant build.xml, or whatever your buildchain is, would be more complicated than simply inserting a gcc cross-compiler.

  • by AtrN ( 87501 )
    It's not just Linux and its not new. I was using it a two years ago to deliver DLLs to some co-workers....
    ; uname
    FreeBSD
    ; head -2 /usr/ports/devel/mingw/Makefile
    # New ports collection makefile for: mingw
    # Date created: 6 June 2000
    ;
  • when they named it? trying to make the transition to windows DIFFICULT by using ENGLISH?
  • XMingWin makes for a very nice tool to use from the Linux side. But the big question is: How well does it work in the area of dynamically loading libraries (.so and .dll stuff) and all the headaches associated with all those #ifdefs in portable libraries!

    As a particular minimal case try: Hello World app using wxWindows for both environments. It would be nice to see if this is a more vialble approach than using the same sources using gcc under Linux and Dev-C++ inder Win* to compile a portable app.

    Just curious...

    Sergio
    • by Anonymous Coward
      I can say from experience that most of the wxWindows samples compile and run quite well. I didn't test them all but all I compiled ran. Some of them are a lot more involved than "Hello World". I made both static and .dll versions of the wxWindows lib and tested them under Wine and NT 4.0

      BTW, here's a quick and dirty HowTo I set up in response to a request from the SunCoast Linux Users Group (SLUG) mail list a week or so ago.

      Ed.

      http://web.tampabay.rr.com/ecentan1/xplat/crossc om pile.html
    • Look no further, http://libsdl.org/ the win32 libs are all built on GNU/Linux.

      now3d
  • by Lumpish Scholar ( 17107 ) on Monday February 03, 2003 @04:56PM (#5217712) Homepage Journal
    Like a lot of people here, I don't get it the point. Cross compilers are for developing for platforms that can't host development tools. When I did cross platform (Windows, Solaris, HP-UX) development, my tools were Vim and CVS plus the native compiler. Which platform would I edit on? Whichever was most convenient that moment.

    On the other hand, for those who want to use MinGW for Windows development, check out the GPL Visual-MinGW [sourceforge.net]. Al Stevens had some very nice things to say about it in the December 2002 issue of Dr. Dobb's. (The article isn't online, but the issue's table of contents is here [ddj.com].)

    There are some significant licensing differences between MinGW and Cygwin. The Cygwin runtime is GPL (not LGPL!), but can be licensed for non-open use. The MinGW runtime is public domain.
  • It is my understanding that this has been doing this for a while, and was actually called a "Canadian Cross Compiler".
    • Canadian Cross is when you are building a cross compiler to be hosted on a different platform than you are building it on.

      Example:
      Using a Linux-x86 system to build a windows hosted powerPC compiler.

      "Canadian" refers to there being three different platforms (parties*) involved: the target platform (powerPC), the hosting platform (windows), and the platform building the cross-compiler (Linux).

      * There used to be three national political parties in Canada before those pesky Quebecois formed a national party.
  • Running mingw32 under Wine to compile Win32 executables. I suppose it still works. Ran perfect for me.
  • A nice article, but the cross-compiler HOWTO is a little out-of-date (circa 1999).


    Having banged my head against a wall over this for a while, I eventually managed to put together a script (based on ideas from Pieter Thysebaert) that builds and installs mingw from latest sources (gcc-3.2.1, binutils-2.13.90, ...)


    The script also works around a couple of problems not described in any of the HOWTOs I've read.


    Anyway, download it from here [gla.ac.uk]

  • by cgf ( 50504 )
    So, this basically sets up a cross compiler?
    And, that's a big deal?

    I've been generating cygwin releases from linux for
    years. I can't believe that this rates as news in
    any way.

    If it does, then the crossgcc mailing list at sources.redhat.com is probably worth checking out. There you can be amazed by the fact that many many people are using cross compilers on a daily basis.

Love may laugh at locksmiths, but he has a profound respect for money bags. -- Sidney Paternoster, "The Folly of the Wise"

Working...