Well, that took me by surprise...
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/will-9-2-be-called-diehard-or-maybe-Naktomi-tp5562525p5836490.html
Sent from the freebsd-hackers mailing list archive at Nabble.com.
___
If this is only difference between gcc34 v gcc42 it's quite spectacular...
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/Threaded-6-4-code-compiled-under-9-0-uses-a-lot-more-memory-tp5756466p5756476.html
Sent from the freebsd-hackers mailing list archive at Nabble.com.
Hello.
While this is old bug upstream:
http://llvm.org/bugs/show_bug.cgi?id=8611
http://llvm.org/bugs/show_bug.cgi?id=8630
Here,
(FreeBSD clang version 3.1 (branches/release_31 156863) 20120523
Target: x86_64-unknown-freebsd9.0)
Passing -g during linking (which lot's of projects do by
Maybe I should include a question too, so I have better chance
of getting answer :)
Is this intended behaviour?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/Clang-g-unused-warnings-in-FreeBSD-linking-tp5727055p5727066.html
Sent from the freebsd-hackers mailing list
Thanks, both replies were very informative!
Regarding
one could argue that passing '-g' to the link stage is nonsensical,
since ld cannot add debug information, it can only remove it (via the '-s'
flag).
Is precisely why I was asking If this was conscious decision on FreeBSD
part.
--
View
Hello.
http://marc.info/?l=openbsd-techm=129236621626462w=2
What's your insight?
regards,
- Jakub Lach
--
View this message in context:
http://old.nabble.com/IPSEC-allegations-tp30464535p30464535.html
Sent from the freebsd-hackers mailing list archive at Nabble.com
Hello.
There's small typo in mptable
output -
Bus Heirarchy
from mptable.c
tableEntry extendedtableEntryTypes[] =
{
{ 128, 20, System Address Space },
{ 129, 8, Bus Heirarchy },
{ 130, 8, Compatibility Bus Address }
};
-best regards,
Jakub Lach
--
View this message
7 matches
Mail list logo