Autoconf 2.69 and mingw

[Thomas Dörfler]

Hi Ralf,

On 21.03.2013 15:13, Ralf Corsepius 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.

ok.

>> - 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 know that for most software, basing it on DLLs has many advantages,
including easier bug fixes. This allows centralized fixes for security
or performance problems, by simply changing/updating the DLLs.

For GCC and binutils, the situation is different from my point of view.
A given combination of GCC code and the libraries may have integrated
bugs, either in the GCC code or in the used libraries. But if we link
the libraries statically to the compiler, at least these bugs are
repeatable. If a user experiences it, it can be repeated (taking the
same compiler binary) without having to mess with the DLL versions used.

And, sorry, when developing software and tracking down bugs, the ability
to get the same output from the same input (using the same tools) is vital.

Ralf, what exactly are your concerns here (except "this is stupid")?

By the way: Some comercial packages (e.g. the XILINX integrated
development environemt including FPGA compiler etc) are shipped that
way. One binary in common for Fedora, CentOS, SuSE, RedHat etc. Tested
on a few versions, but working on MANY of them.
> 
>> 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.

but for glibc most platforms support a good backward compatibility.
> 
>> - 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.

Which incompatibilities do you mean exactly? Between GCC and a certain,
statically linked library? Between a library and the OS basis?
> 
>> - have repeatable results when compiling even on different hosts
> Well, yes, all bugs would be hard wired.

Yeah, speaking frankly this is the only way they should be. If I get a
bug, i want it ALWAYS. Hardwired, if possible. It's much easier to track
it down.
> 
>> 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.

I value your experience on the tooling front, that's wh I started this
discussion.

I would love to be convinced on a technical basis, if my proposal is
bullshit. But as an engineer, I hate "forbidden" questions.

Thomas.
> 
> Ralf
> 
> 
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel


-- 
!!! Neue Adresse !!! New Address !!!
--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler        Dornierstr. 4
D-82178 Puchheim       Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18 94 741-12
Fax:   +49-89-18 94 741-09