I've got a really amazingly bizarre bug, when running my modified
gcc under gdb, I see some bewildering behavior. So, before I start
debugging at the assembly level, I'd like to see some .s files.
This led me to try adding "-save-temps" to the CFLAGS and
CXXFLAGS on the make command line. This in t
On Mon, 2008-12-15 at 11:37 +0100, Gerald Pfeifer wrote:
> Steve et al,
>
> I don't think I have seen a response to this, and it might be the same
> issue that was causing quite many testsuite failures on i386-unknown-freebsd
>
> If so, that would be GCC Bugzilla Bug 35114, "731 unexpected libgom
Steve et al,
I don't think I have seen a response to this, and it might be the same
issue that was causing quite many testsuite failures on i386-unknown-freebsd
If so, that would be GCC Bugzilla Bug 35114, "731 unexpected libgomp
testsuite failures due setup of test environment", or
http://gcc.g
On Tue, Nov 4, 2008 at 12:56 PM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> To fix it in libtool I think we would have to stop using +nodefaultrpath
> when building shared libraries so that there is a search path to use in
> the shared libraries. This seems simple but I am not sure about all the
>
I have a libtool / gcc / libgomp / shared library question. The problem
I have is that if I compile a C program with -fopenmp and run it on IA64
HP-UX I get:
$ ./x
/usr/lib/hpux32/dld.so: Unable to find library 'libgcc_s.so.0'.
The problem is that the GNU C compiler links the program against the
rking on the problem, but each has his or her own
> priority and funding resources.
>
> You should ask these questions publicly, not contacting individual
> developers privately.
>
> David
>
> To: David Edelsohn/Watson/[EMAIL PROTECTED]
> cc:
&
