Re: [Mingw-cross-env-list] what belongs in mingw-cross-env/usr/i686-pc-mingw32/bin?

[Volker Grabsch]

Mark Brand <address@hidden> schrieb:
> I am wondering which files are supposed to end up in
> mingw-cross-env/usr/i686-pc-mingw32/bin. I see 4 categories:
> 
> 1. Executables that run on the build system and play a role in building
> software for the target system.
> 2. DLLs for the target architecture.  Needed for preparing packages for
> target system and testing under Wine.

This is a dangerous generalization. Currently, there is just
one package doing this - the mingwrt-dll package with its file:

    usr/i686-pc-mingw32/bin/mingwm10.dll

And this is not a DLL built by mingw-cross-env - it's just
downloaded directly from MinGW project. It's not even a "real"
DLL that contains a "real library". It's just a workaround-DLL
for the support of threadsafe exceptions, and is completely
useless outside the scope of MinGW.

There's exactly one other package that does something with
DLL files - the LibUSB. But it doesn't build any DLL files,
as this simply wouldn't make sense. In our context, where
everything is avaiable for static linking, the whole point
of linking against DLL files is to be able to use officially
provided DLL files. That's why we just need to build stub
libraries and to install the header files.

So in any case, DLL files shouldn't be built with mingw-cross-env.
Instead, the official binary/DLL packages should be used.
And BTW, exactly that's the case with "mingwm10.dll", too.

> 3. Executables (.exe) for the target architecture. Some of these are
> useful to have since they can be used as components in packages prepared
> for the target platform.

It is true that some library packages contain programs, which
fall into one of the 4 categories:

    * Example programs
    * Test programs
    * Command line utilities
    * Code generators needed by the build

Note that none of them are interesting for us as win32 binary:

    * Example programs are only interesting in source form

    * Test programs rarely run with Wine

        (I think that when we want to add testing support
         to mingw-cross-env, the only solution that is working
         and maintainable for all libraries would be hand-written
         or automatically generated programs.)

    * Command line utilities are usually not needed. The
      only exceptions are GCC, Binutils, Pkg-config, Gettext
      and Qt, but these are built natively, not cross, and
      that the. They usually also get a symlink to usr/bin:

          usr/bin/i686-pc-mingw32-TOOL   ->   /usr/i686-pc-mingw32/bin/TOOL

    * Code generators are worthless when cross-compiled. They
      need to be compiled natively, and they aren't installed,
      because they aren't needed any longer after the build.

That is why almost all packages are told not to install their
binaries, either via ./configure arguments or via Make variables.

> Can also be used for testing under Wine.

This is a very problematic argument for two reasons.

First, mingw-cross-env is meant to be indenpendent of Wine, because
most programs don't run properly in Wine, and because a dependency
on Wine would make it much harder to make mingw-cross-env run
on any Unix platform.

Second, mingw-cross-env simply follows another strategy. If you
really want to design around Wine, many things will simplify. For
instance, you wouldn't need any cross-compiler workarounds, so you
could greatly simplify the build scripts. You also wouldn't have
to build a cross-compiler anymore - just use the official MinGW
GCC/Binutils binaries. On the other hand, you'd have to make several
Unix tools like Bash, Perl, Scons etc. available in Wine. Some of
them are provided by MinGW's MSYS package, some are provided by
the projects, but most aren't - they might be avaiable as Cygwin
packages, but Cygwin doesn't run under Wine.

So if you go that way, you should go it straight, and would end
up in a completely different project.

BTW, I really considered going that route with mingw-cross-env.
However, I abandoned it because the downsides appear to be a great
amount more troublesome than our current cross-compiling problems.

> 4. Shell scripts. A shell script could be intended for use on the build
> system, but could also be useful on the target system running on MSYS.

Shell scripts also fall into one of the above categories, where
only the third kind (command line utilities) would be interesting.

> Is it acceptable to mix architectures in "bin"?

I don't think it is acceptable to put any DLL or EXE files
into bin/. I don't think it's a good idea to even build them.
Either build them natively or don't build them.

The only win32 binary in bin/ is "mingwm10.dll", but it is a
nasty work-around and thus a bad candidate for generalization.

Note, however, that there's a related question of where to
put externally downloaded DLL files. I don't think they need
to go into mingw-cross-env's usr/ directory. But if there
appears to be a good reason for doing that, our "bin" directory
(i.e. usr/i686-pc-mingw32/bin/) would be the candidate which
fits best.

> I'm curious to know what Volker and others think about this.

I hope I was able to clear things up a bit. And I'm also curious
about the experiences of other users.


Greets,

    Volker

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