On 08/01/14 09:11, Thomas Orgis wrote:
I attached our build script from the old RHEL 5.3 installation. No guarantees that it will solve your issue, but we didn't have any such issues on that system.Am Fri, 01 Aug 2014 06:58:23 -0500 schrieb Jason Bacon <jwbacon%tds.net@localhost>:If I recall, it should only require using the proper rpath flags while building gcc. And yes, we use packages requiring Fortran and C++ extensively.That is the crucial point. So I should talk to my colleagues to achieve that in future builds. I didn't realize that this is possible for GCC. At least, it's not talked about much. For now, the fixed -Wl,-R/path/to/lib works, but I agree that for our kind of setup, the compiler inserting rpath itself would reduce issues a lot, to the extend that the shell module for using a compiler indeed only needs to put it into the path (unless there's funky C++ "libs" in header form associated, but of course the compiler could/should put those include paths into its own internal view, too).
I can also tell you that the FreeBSD gcc ports had this issue a while back. They install the core libraries into /usr/local/lib/gccXX and some binaries built from them were loading like-named libraries from /usr/lib instead. I had to add -rpath to several ports that depended on a gcc port. This issue has been resolved, so you might benefit from examining the current gcc port Makefiles if the attached script doesn't light the way.
Hadn't thought about it, but I'll avoid CC'ing in the future. Thanks for the head-up.Hm, off studying GCC manual/source tarball, I guess Alrighty then, Thomas PS: Is it general consensus on pkgsrc-users to send copies per CC? I usually prefer to just get the mail via the list. Confuses my automatic sorting less, too.
JB
Attachment:
build.sh
Description: application/shellscript