gcc-2.95.2-2, VxWorks, CygWin: Can't build it.
Dave Korn
I'm being driven slowly out of my mind.
I am trying to build gcc-2.95.2-2 for the powerpc-wrs-vxworks target
on a PC using NT4.0sp6 and a fairly recent (1.1.2) download of cygwin.
It goes dreadfully wrong, no matter what I try.
I've searched various mailing list archives (gcc-help, crossgcc, cygwin),
and found that lots of people have been having trouble with it under all
sorts of platforms, but no mention of cygwin.
Has *anybody* managed to build this target under cygwin? Anyone at all?
My main problem at the moment is to do with errors compiling
choose-temp.c in libiberty which is suffering some sort of header
conflict that prevents it knowing the definition of a va_list:
/usr/home/dkorn/gcc-2.95.2-2/libiberty/../include/libiberty.h:193: parse
error before `va_list'
...despite having successfully completed the fixincs step. And that's not
all...
/usr/home/dkorn/gcc-2.95.2-2/libiberty/choose-temp.c: In function `try':
/usr/home/dkorn/gcc-2.95.2-2/libiberty/choose-temp.c:89: warning: implicit
declaration of function `access'
/usr/home/dkorn/gcc-2.95.2-2/libiberty/choose-temp.c: In function
`choose_temp_base':
/usr/home/dkorn/gcc-2.95.2-2/libiberty/choose-temp.c:111: warning: implicit
declaration of function `getenv'
/usr/home/dkorn/gcc-2.95.2-2/libiberty/choose-temp.c:138: warning: implicit
declaration of function `mktemp'
/usr/home/dkorn/gcc-2.95.2-2/libiberty/choose-temp.c: In function
`make_temp_file':
/usr/home/dkorn/gcc-2.95.2-2/libiberty/choose-temp.c:157: warning: function
`getenv' was previously declared within a block
/usr/home/dkorn/gcc-2.95.2-2/libiberty/choose-temp.c:192: warning: implicit
declaration of function `strcat'
/usr/home/dkorn/gcc-2.95.2-2/libiberty/choose-temp.c:200: warning: implicit
declaration of function `close'
I won't go into further detail right now, as I'm sure most people aren't
interested. But if *anyone* out there has built this version, can you
please drop me a line and tell me whether you had similar trouble, and
what kind of configure options you used ?
Thanks for your time,
DaveK
--
What part of "Gestalt" don't you understand?
Gary Beck
powerpc-wrs-vxworks target. I know that Tornado 3.0 (still in beta)
will be using GNU 2.95 for their toolset but we need to work with
Tornado 2.0, VxWorks 5.4.
The reason I need GCC 2.95 rather than the Tornado shipped toolset
(2.72) is the optimization. Version 2.95 is much better than 2.72.
Also, the compiled Cygnus version 2.95 (powerpc-eabi) does not work
with the CrossWind Debugger.
Any help in this area would be appreciated.
Dave Korn
><no....@my.mailbox.invalid> wrote:
>> Hi everyone,
>>
>>I'm being driven slowly out of my mind.
>>
>>I am trying to build gcc-2.95.2-2 for the powerpc-wrs-vxworks target
>>on a PC using NT4.0sp6 and a fairly recent (1.1.2) download of cygwin.
>>
Gary Beck wrote in message <3989cf0e...@24.0.240.30>...
>I am also interested in how to compile gcc-2.95.2-2 for the
>powerpc-wrs-vxworks target. I know that Tornado 3.0 (still in beta)
>will be using GNU 2.95 for their toolset but we need to work with
>Tornado 2.0, VxWorks 5.4.
I'm fairly sure that the problems only exist under cygwin, as I've had
reports that it builds fine under Linux.
>The reason I need GCC 2.95 rather than the Tornado shipped toolset
>(2.72) is the optimization. Version 2.95 is much better than 2.72.
You're not joking. The bugs in the 2.7x optimization are so serious as to
render it unuseable in production code. We've got a code base of about
half-a-million lines and bugs relating to the optimisation of short-circuit
logical expressions and common subexpression elimination have sprinkled
bugs throughout the compiled code. It's possible to use temporary variables
holding partial results to work around this bug but there's no way to find
out where in the code we have expressions that will be miscompiled.
>Also, the compiled Cygnus version 2.95 (powerpc-eabi) does not work
>with the CrossWind Debugger.
You might be able to rebuild gdbppc from the latest sources. I don't
know if that would fix it though. People have discussed this before, so it
might be worth your while to search a) the windsurf support site, b) the
various gcc related mailing-list archives at www.gnu.org
Good luck!
DaveK
--
"Reality is whatever doesn't go away after you stop believing in it."
-- Philip K. Dick
Ami Ghua
Does there exist any safe optimization flags that will avoid all these
problem optimizations?
Ami
On Thu, 3 Aug 2000 13:54:18 +0100, "Dave Korn"
<no....@my.mailbox.invalid> wrote:
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Tim Michals
under ECOS.
Ami Ghua <big_...@bigfoot.com> wrote in message
news:398bb68d....@news.usenet-access.com...
Dave Korn
>On Thu, 3 Aug 2000 13:54:18 +0100, "Dave Korn"
><no....@my.mailbox.invalid> wrote:
>
>>Gary Beck wrote in message <3989cf0e...@24.0.240.30>...
>>
>>>(2.72) is the optimization. Version 2.95 is much better than 2.72.
>>
>> You're not joking. The bugs in the 2.7x optimization are so serious as
to
>>render it unuseable in production code. We've got a code base of about
>>half-a-million lines and bugs relating to the optimisation of
short-circuit
>>logical expressions and common subexpression elimination have sprinkled
>>bugs throughout the compiled code. It's possible to use temporary
variables
>>holding partial results to work around this bug but there's no way to find
>>out where in the code we have expressions that will be miscompiled.
>>
>
>Does there exist any safe optimization flags that will avoid all these
>problem optimizations?
>
>Ami
I haven't had any trouble with -O0. I have had trouble with -O1.
YMMV.