Re: [Mingw-cross-env-list] Fwd: Re: [Mingw-users] Compiling on Linux with a windows target

[Volker Grabsch]

Mark Brand <address@hidden> schrieb:
> Shared linking makes sense for big platform-type libraries such as GTK 
> or (not yet in mingw-cross-env) Qt. If I'm developing a Qt application, 
> I'm generally aware of which Qt DLLs the application needs, so it's not 
> much trouble to package them with the application. Static linking Qt 
> libraries also carries complications for using plug-ins, which argues 
> for shared. Similar considerations might exist for GTK.

On the other hand, if your main platform isn't Windows, you usually
have no interest in providing plugins separately, especially in a
free software project. So there shouldn't be a problem in just linking
the plugins statically, too.

Or, turned into a question: Did you encounter any scenarios where
it was really practical to provide plugins as separate DLL files
for your application? ... in a free software application with free
software plugins?

> Of course, where practical, a package's makefile in mingw-cross-env 
> could be configurable to accommodate personal taste.

Well, this is exactly the kind of testing and maintainance nightmare
I'd like to avoid.


Keith Marshall wrote:
> If there isn't, there should be!  On Ubuntu-8.04, (and on SUSE-10.0
> previously), I compile my own MinGW cross-compiler from source; I
> invoke it as `mingw32-gcc ...'.  Some may choose to add the `i386'
> (or equivalent `i?86') CPU designator and `pc' VENDOR identifier,
> (which is rather meaningless), but in reality, both of these are
> mostly redundant;

IBTD. The CPU designator should always be given, as it is
important to know whether your compiler will emit e.g. special
i686 instructions or not.

In contrast, the "pc" VENDOR is really redundant. But I think
we should follow the Autoconf manual and add it for consistency.


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR