Autoconf 2.69 and mingw

[Thomas Dörfler]

Hi,

On 21.03.2013 16:35, Ralf Corsepius wrote:
> On 03/21/2013 03:36 PM, Gedare Bloom wrote:
>> 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:
>>>
>>>> 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?
> 
> statically-linked binaries are a nightmare, security risk, and cause of
> bloat. In some cases, it's not even possible to link statically.

I ignore "nightmare", since this depends neither on the binary nor the
host, but the user :-)

Regarding security risk: I understand this argument for many programs,
especially those with root capabilities (suid) or communication
channels. But I don't see, how this applies to gcc and binutils. They
take a bunch of input files, convert them, write to the output. They are
(should be) limited to the jail each user is in. So for this group of
programs, security issues seem quite unlikely for me. It is much more
likely, that a modified "improved" DLL may subtly change the GCC
behavior and let in generate different code.

>>>
>>> Glibc alone, is moving at a pace this is hardly possible.
>>>
>> What does that have to do with anything?
> 
> A lot, ...
> 
I don't see that. As a matter of fact, I still use a
powerpc-rtems4.8-gcc (GCC) 4.1.2 (RTEMS gcc-4.1.2/newlib-1.15.0-9) for
maintenance of an old RTEMS project. It is still runable on an
up-to-date openSuSE 12.x, although it was built on 9.x.

It's not a prove that this will ALWAYS work, but since most distros
provide backward-compatible libraries this looks promising.

>> 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?
> 
> No. This is non-applicable. Native tools and libc are none of RTEMS
> business - This is what system-integration is about and what packageing
> tools take care about.

Sorry, I must strongly disagree: A proven combination of GCC and
underlying libraries is definitively RTEMS business. Otherwise a tested
version of RTEMS can only be reproduced on a single Host
OS/Toolset/RTEMS combination, which lets the number of permutations explode.

> 
> This "link everything statically" is naive Windows-newbie school.
> 

Lol.

>>>> - 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!
> Are you aware of any?

Have you tested against it? Do we have a test that proves, hat we get
the same binary code from a given toolchain version on all hosts?

wkr,

Thomas.

> 
> 
> 
> _______________________________________________
> 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