Autoconf 2.69 and mingw

[Gedare Bloom]

On Thu, Mar 21, 2013 at 10:13 AM, Ralf Corsepius
<ralf.corsepius at rtems.org> wrote:
> 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.
>
Why is it impossible?

>
>> 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.
>
What would such an installer require?

>
>> 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.
>
I don't understand---what is wrong with a static-linked toolchain?

>
>> 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.
>
What does that have to do with anything? We should have a
fixed/working version of the library that is tested and used by
many... Right now we rely on the upstream distro to provide it through
package dependencies in RPMs, and users who do not rely on the RPM
infrastructure will be stuck with whatever host tool they use and do
not know what everyone else does. Would it not be better for us to
specify a version of e.g. glibc, gcc, binutils, for the host, and
newlib, gcc, binutils for the target?

>
>> - 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.
>
This is much better than bugs showing up only under random host/build
combinations!

>
>> 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
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel