On Mon, Jul 08, 2013 at 10:51:10AM +0100, Gianfranco Costamagna wrote: > > Yes, but what does that have to do with the commit you linked? Doesn't > > it just add the symlink? > > I honestly don't know, linking it locally makes gcc (4.6) to fail the linking > of the file. > without the link gcc automatically finds the right location without any > problems
Well, maybe I'm missing something. Let me say what it looks like: * The BOINC app samples link against libstdc++ statically on x86 because they're meant to run on the *clients*, and Linux clients might not have the right libstdc++ available. The binaries are not meant to run on the server machine! * The commit you link fixes the build, by adding a symlink to libstdc++.a, but it doesn't add libstdc++.a to the $(CXX) command line: it's already there (and it's been there for a long time, for the reason above). * Your patch removes libstdc++.a entirely, from the $(CXX) command line, which means you get binaries dynamically linked against libstdc++. That doesn't revert the commit you linked, but instead makes a different change (one which produces binaries which might not work on old x86 client Linux machines). If that last bit is wrong then, sorry, I've misinterpreted your patch. But it does seem also that building the app samples in the Debian/Ubuntu packages is pointless, since you want to build them targetting an old libc anyway, right? So usually they should be built on a VM or in a chroot. So Bernd Machenschalk's suggestion for a --disable-example-apps or something might be a good idea, I don't know. - Alyssa _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
