thanks.. mea culpa, I assumed that 'testing fixes' solely meant making
the fixincludes ready for release..
Ed
On Tue, Oct 21, 2008 at 9:49 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
>> Yes, I got that from the README. What I was looking for was a
>> *shortcut*,
>
> "5. Testing fixes" precisely
> Yes, I got that from the README. What I was looking for was a
> *shortcut*,
"5. Testing fixes" precisely documents a shortcut.
--
Eric Botcazou
Eric,
Yes, I got that from the README. What I was looking for was a
*shortcut*, ie: I compile ~1000 packages, so when one doesn't work, I
trace down the reason, compose a entry in the 'live' fixincludes.def,
and after I'm done with the 1000-or-so packages take all the bugs in
one step back to the
2008/10/19 Edward Peschko
> Constructs of the form
>
> extern enum vtype iftovt_tab[];
>
> are now failing with forgiving
>
> error: array type has incomplete element type
>
> This would be fine if it was code that I controlled - but the matter
> of fact is that this code is in /usr/include/sys/mod
> Is there any way to do this work with an already installed compiler,
> ie: change the fixincludes.def on the fly and have the installed
> compiler immediately pick up on the changes from the text file?
You need to work in a build tree, modify fixincludes.def and follow the
instructions given in
Eric,
I'm looking at it, and that's one hell of an amount of work to do for
the code that I would maintain. As far as I can see, it requires me to
recompile/reinstall the compiler for every issue that I find..
Suppose I find fifty such issues?
Is there any way to do this work with an already inst
> I'm not sure what you are trying to say here - that it should be fixed
> locally on my side at the level of the header file? Or something else?
That it should be fix-included, see fixincludes/README in the source tree.
--
Eric Botcazou
Eric,
I'm not sure what you are trying to say here - that it should be fixed
locally on my side at the level of the header file? Or something else?
Fixing locally really isn't feasible as I'm working with a large
amount of code (a whole code distribution, in fact) and who knows how
many anachronis
> This is having the unfortunate side effect that a lot of packages that
> used to compile perfectly fine with gcc-3 are no longer doing so with
> gcc-4.
The major Linux distributions use GCC 4.x so this should be doable.
> Here's another example I'm finding:
>
> Constructs of the form
>
> extern
Eric,
I don't want to be a hair-splitter, but I do think this message does
belong in gcc - it's a question of functionality, and how easy to use
gcc is.
I am trying to move to gcc-4 for its technical improvements, but I'm
finding that it seems to be far less forgiving than gcc-3.
This is having
2008/10/19 Edward Peschko:
>
> That worked (thanks) but exactly why did it work? Shouldn't gcc be
> smart enough to realize that it is working either with a c++ file or
> linking to a c++ library?
http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Invoking-G_002b_002b.html
"g++ ... automatically specifi
H.J -
hmm.
That worked (thanks) but exactly why did it work? Shouldn't gcc be
smart enough to realize that it is working either with a c++ file or
linking to a c++ library?
Ed
It's part of a configure test as part of
On Fri, Oct 17, 2008 at 9:24 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> On Sat,
On Sat, Oct 18, 2008 at 11:13 AM, Edward Peschko <[EMAIL PROTECTED]> wrote:
> All,
>
> I'm trying to compile a thread with the boost, threading libraries,
> and am getting errors like these.
>
>gcc -o conftest -g -O2
> -I/GAAL/pesced_release/install/fuego/include/boost-1_36
> -L/GAAL/pesced_rel
13 matches
Mail list logo
