On 29.04.2014 13:44, Panagiotis Christopoulos wrote: > On Tue, Apr 29, 2014 at 2:36 PM, Panagiotis Christopoulos > <[email protected] <mailto:[email protected]>> wrote: > > ... > > if you open the original sources (without eautoreconf), and go > inside omalloc folder, you'll find the cause in line 120 of > configure.ac <http://configure.ac> and/or 12977 of configure. It's > hardcoded there that the script should fail if $ac_cv_prog_AR is not > "ar". Here, portage already passes (even without your tc-exports > etc.) the correct environment to singular's build system but > "x86_64-pc-linux-gnu-ar" is not "ar". You could remove that check at > all but I'm not a toolchain expert and don't know why the check is > there in first place. On my box ar just links to > x86_64-pc-linux-gnu-ar so no big deal. > > > of course , name changes may affect program behariour ($0) so ar might > have different results if you invoke it as "ar" than > "x86_64-pc-linux-gnu-ar". I would remove or replace the configure check > and would do some testing to see what happens. Was omalloc and that test > included on previous versions too?
OK, thanks for coming up with this. We did not use omalloc before, but I thought maybe we should because Singular upstream told me that using system malloc is bad (I don't remember if it was just performance or also other problems). The omalloc build system seems to be old, so maybe it was back in the old days that some other ar on some esoteric platform failed on them and it was band-aided with this check? Cheers, Thomas
signature.asc
Description: OpenPGP digital signature
