Bob Atkins added the comment:
3 years and counting while everyone rings their hands and debates this
trivial issue.
3 years and counting while hundreds of builders encounter this problem
wasting countless of hours troubleshooting, possibly re-reporting the
problem.
Software is not a religion
Bob Atkins added the comment:
I see that Martin's broken record still hasn't changed. I had warm,
nostalgic feelings as I re-read this thread. It is so sad to see that
this matter remains unresolved almost 3 years after I filed this bug.
As usual Martin is just flat wrong in his
Bob Atkins <[EMAIL PROTECTED]> added the comment:
I rest my case - you found /_*one*_/ of the problems which you are
blaming on gcc but in fact is not gcc's fault. You /_*must*_/ specify
the correct -L and -R paths to the various alternate 64 bit libs. Don't
expect the compi
Bob Atkins <[EMAIL PROTECTED]> added the comment:
Martin,
Your method is just flat wrong - equivalent to using a sledgehammer. The
libraries fail to link not because gcc install is wrong but because the
-m64 flag needs to be passed to the linker. Your method just fixes the
compilation
Bob Atkins <[EMAIL PROTECTED]> added the comment:
Martin,
Martin v. Löwis wrote:
It does not when link stage specific options are required that are not
valid for compilation stages.
My mistake. I was thinking of another package - you can scratch that
comment.
There is no hard and fas
Bob Atkins <[EMAIL PROTECTED]> added the comment:
Martin,
I've been quietly reading all of the back and forth regarding this problem.
Your suggestion for using the CC variable to fix the problem that I
reported won't work - I already tried it and based on what others are
re
