x86_64 Linux system (Gentoo) w/ gcc 4.6.2 and Studio 12.3 (tar).Sorry, Gentoo is not a supported system (though something might still work).
Am I assuming correctly that if I use -compat=g or use stlport4, I cannot make use of the optimized math library that comes with the compiler suite as a replacement for the regular libmMath stuff is not C++ specific, so it does not matter what -compat mode or STL do you use.
heavy use of the STL and boost. The standard libCstd does not support every feature - which also goes for some of the project's dependencies as well. Is the stlport4 or the native g++ stl the only way to solve this?We claim support for Boost with -compat=5 -library=stlport4 mode only.
With every compile, I get "CC: Warning: failed to detect system linker version, falling back to custom linker usage".Old Linux linkers (GNU ld, versions predating 2.20) are not able to properly handle C++ objects generated by Studio.
I have a small test program which basically is a loop that iterates UINT32_MAX times and does some calculation. I use OpenMP's parallel for without any hint to scheduling, number of threads or such. All compilers (g++, icc, path64) I tried, correctly put out 8 threads to handle the load. Except for the version compiled with solaris studio compiler. It only launched two threads and came in last. After manually forcing it to 8 threads (OMP_NUM_THREADS=8), it worked like a charm and even took the lead. Again, it is a simple and stupid test. But I wonder what I am missing because it should not be the user's job to set the right number of thread for his machine.Wonder what kind of hardware do you have?
Sorry, Gentoo is not a supported system (though something might still work).I know. That goes for most software, actually... and one gets used to it, if you do not use one of the major distros. But on the other hand, it rarely causes any problems that cannot be solved.
And gcc 4.6.2 is definitely not supported for -compat=g. [...]Ah, okay. Thanks for that information. That explains a lot and I will stay clear of it in the future until I read otherwise in the release logs. :)
Math stuff is not C++ specific, so it does not matter what -compat mode or STL do you use.At least that door for a good speed up is still open. Nice to hear.
We claim support for Boost with -compat=5 -library=stlport4 mode only.-library=stlport4 implies -compat=5, if I am not mistaken? Or -compat=5 is the default anyways. I remember having read something about it.
It seems that your system linker has --version output that CC cant match, so it runs old linker shipped with Studio.Is there any way I can workaround that or force the compiler to use my linker nevertheless?
Its not going to do anything good :(
Wonder what kind of hardware do you have?Core i7 860 (4 real cores + 4 HT).
Either our heuristics happens to not match your test program, or the runtime fails to detect the number of CPUs on your system.I would guess it is most likely the latter. Is there any way I can force debug information about this?
-library=stlport4 implies -compat=5,Yes, that was somewhat ambiguous.
Is there any way I can workaround that or force the compiler to use my linker nevertheless?I cant see non-cumbersome workarounds currently. Will get back to it later.
I cant see non-cumbersome workarounds currently. Will get back to it later.For now, I've replaced the bundled "ld" with a symlink to the system one. :)
khaos wrote:A hack (and it's just that) is to edit bfd/configure, changing PKGVERSION="(GNU binutils) " to "*PKGVERSION="version "*. That changes the version text from GNU ld (GNU Binutils) 2.23 to simply GNU ld version 2.23 which is recognized by CC as a valid version string. Rebulld and install that modified version of the binutils package.
write(2, "failed to detect system linker v"..., 76failed to detect system linker version, falling back to custom linker usage
That changes the version text from GNU ld (GNU Binutils) 2.23 to simply GNU ld version 2.23 which is recognized by CCIndeed, CC matches version text with "GNU ld version" string. This is what linker on our supported platforms reports.