Autoconf 2.69 and mingw

[Ralf Corsepius]

On 03/21/2013 02:43 PM, Thomas Dörfler wrote:
> Hi,
>
> I don't know about mingw auto* packaging, but for me this is another
> indication that we should in the future leave the path of basing our
> tools on the host packaging system.

This is impossible for scripted languages/tools, such as the autotools 
when canadian cross building.

> Looking at this auto* version issue, the discussion about libraries not
> being present on a certain host etc, we should move to provide our tools
> as packaging-independent tarballs.

The problem with mingw is there not being any viable upstream 
distribution, which can be used as a basis for building.

That said, their are 2 competing mingw system: mingw32 and mingw32-w64. 
The former is pretty much dead, while the latter is actively maintained 
and moving forward. Also, mingw32-w64-i686 is supposed to be compatible 
with mingw32.

That said, the origin of mingw issues typically is the user, who is not 
able to setup the infrastructure underneath.

What lacks for mingw is an rtems toolchain installer, nothing else and 
nothing less.

> This means:
> - building GCC and tools with statically linked libraries (no more
> dependency on DLLs except libc)
This is a very silly and naive idea, one I am used to be confronted with 
by inexperienced new-comers. Makes me wonder why it comes from you.

> What I would expect from this would be:
> - have ONE tarball fit all Linux flavours (and for each major host family)
Glibc alone, is moving at a pace this is hardly possible.

> - get less problem reports due to packaging incompatibilites
Wrong - You just would not see the incompatibilities, because you would 
not test for them and you would not see the build-incompatibilities.

> - have repeatable results when compiling even on different hosts
Well, yes, all bugs would be hard wired.

> I know this is a big step, but I don't really see what major reasons
> stand against this.
With all due respect, but politeliness prohibits to go into further details.

Ralf