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_release/install/fuego/lib /tmp/aa.c
-lboost_thread-gcc43-mt
/GAAL/pesced_release/install/fu
wrote:
> 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
>
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
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
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
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
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
All,
dbx has a feature called 'trace' where it outputs your program
execution, a line at a time, and I've found it very useful for
debugging/figuring out programs (you run it once, make a change, run
it again, and do a diff to see exactly how your change affects the
programming run).
However, it
Richard,
Thanks for the info... I'll try it out - I'm assuming that what you
get out of this is very similar to what you get out of dtrace when you
instrument a pid on entry and return.. Having a full trace is very
helpful in tracking things down.
I'd like to go further in c code even than what I
place, ie: add extra code of my own choosing that I would then
compile with gcc.
How feasible would that be? Where's a good place to start?
Thanks,
Ed
On Fri, Oct 31, 2008 at 11:24 AM, Edward Peschko <[EMAIL PROTECTED]> wrote:
> Richard,
>
> Thanks for the info... I'll
All,
I'm just curious - what version of gcc has the latest stable gcj? I've
been trying to build gcc-4.4.0 on solaris and have been running into
multiple issues:
1. gperf (version 3.0.4) generates incorrect code killing the build:
../.././gcc/cp/cfns.gperf:84: error: 'gnu_inline'
All,
When I link with a shared library, for example:
env LD_RUN_PATH="/usr/lib" /usr/bin/gcc -shared -fPIC
-L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o
blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib
/usr/lib/libconfig.so
the ld command follows the version, and
All,
I found much to my dismay today that -I doesn't always work as
intuited. Namely, if I set CFLAGS to:
-I/path/to/gcc/include
where the default system path is:
/path/to/gcc/lib/gcc/i686-pc-linux-gnu/3.4.6/include
/usr/local/include
/path/to/gcc/include
/usr/include
the expected behavior wou
All,
Got the following error in compiling the latest version of mysql
(mysql-5.6.13). I'm not sure if this is a gcc problem or a mysql
problem, but it looked very standard library related, so I thought I'd
point it out here.
I look at the stl_list.h file and see it is in an #if block, with
#if _
14 matches
Mail list logo
