[Rivet] --no-as-needed only exists for ELF linkers

[James Monk]

I fully agree.  I actually don't use the bootstrap, preferring to decide for myself where everything is going to install.  I think things will become a lot smoother once the dependencies have stabilised; lately I've had to keep on the bleeding edge of things like boost and yaml, and it will be nice if the minimum version could stay still for a while :/

Would I be right in thinking a lot of the autotools incompatibilities come from boost.m4?  We have a CENT OS system here, and that too didn't play nicely with that macro.  configure.ac declares that it needs autoconf 2.59, but boost.m4 actually only works with 2.6.  As a final insult, it wasn't even able to link the libboost_iostream without me tweaking it by hand - for some bizarre reason it expects the library to be named libboost_iostreams-gcc41-mt-1_54.so, completely ignoring the more obvious libboost_iostreams.so that actually exists.

cheers,

James

On 23 Jul 2013, at 17:05, Andy Buckley wrote:

> Hi Frank, these sound like good things to push. I've had problems with
> the lxplus (5 and 6) autotools installations, and the LCG autotools has
> been fundamentally broken by splitting the tools into separate
> installation trees: turns out they don't like that.
> 
> It would be *so* nice to be able to get rid of the bootstrap, if HEP
> systems were generally sane and up to date, but I don't see that
> happening any time soon! But I do think we should aim to split into a
> rivet1-bootstrap for Rivet 1.x and a rivet-bootstrap for the 2.x series
> (and in general the active production series)... so much of the mad
> complexity in that thing is trying to deal with situations like "if
> you're on a system with AFS and you're installing from hg but you want
> the AIDA branch and you want to install a private autotools, but
> not...". To keep it maintainable I think it needs to be restricted in
> scope, and cleanly cutting out support for the 1.x branch from the
> maintained version of the script is the cleanest way to start.
> 
> Andy
> 
> 
> On 23/07/13 16:54, Frank Siegert wrote:
>> While we're at it: for me the yaml-cpp tests failed to build on a
>> cluster (don't remember exactly why), so I disabled them in the
>> bootstrap script with the -DYAML_CPP_BUILD_TOOLS=OFF cmake option. If
>> there are no objections I'd also push this change.
>> 
>> Another issue is the --install-autotools option: It doesn't install
>> m4, which means that autoconf can't be built if the system m4 is too
>> old. Again, if there are no objections, I'll add the m4 installation
>> to --install-autotools.
>> 
>> By the way, in case somebody runs into this as well: I've had an issue
>> on two completely different clusters now (both possibly SuSE-based
>> though?) that Rivet wouldn't build with the default libtoolize 2.2.6
>> because the libtool step simply produced no output:
>> 
>>  make[2]: Entering directory `/.../build/rivet/src/Core'
>>    CXX    libRivetCore_la-Event.lo
>>  mv: cannot stat `.deps/libRivetCore_la-Event.Tpo': No such file or directory
>> 
>> Using --install-autotools solved that.
>> 
>> Cheers,
>> Frank
>> 
>> 
>> 
>> On 23 July 2013 16:39, Andy Buckley <andy.buckley at cern.ch> wrote:
>>> Precisely! Please add :-)
>>> 
>>> On 23/07/13 16:35, James Monk wrote:
>>>> while we're on the subject of niggly little build snafus, I've noticed that the yaml-cpp lib path probably needs to be added to rivetenv.sh.in.  This is exactly the sort of thing we want to iron out for a 2.0 release, so I guess it's ok to add that to trunk this time!
>>>> 
>>>> cheers,
>>>> 
>>>> James
>>>> 
>>>> 
>>>> On 22 Jul 2013, at 21:54, Andy Buckley wrote:
>>>> 
>>>>> Just checking up on this... and thanks to hg blame I know it's Hendrik
>>>>> who added that flag ;-) What was the motivation for it? For all other
>>>>> flags we check them first via the configure script... do we really
>>>>> require --no-as-needed in plugin building on Linux?
>>>>> 
>>>>> Andy
>>>>> 
>>>>> 
>>>>> On 17/07/13 16:01, James Monk wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> The linker flag --no-as-needed has been added to the rivet-buildplugin script recently.  As far as I know, this only exists on Linux, certainly it causes my linker to fail on OS X.
>>>>>> 
>>>>>> Can we add a check for OS X as already occurs for the shared library flags, and revert to the old behaviour in that case?
>>>>>> 
>>>>>> cheers,
>>>>>> 
>>>>>> James
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Rivet mailing list
>>>>>> Rivet at projects.hepforge.org
>>>>>> http://www.hepforge.org/lists/listinfo/rivet
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Dr Andy Buckley, Royal Society University Research Fellow
>>>>> Particle Physics Expt Group, University of Edinburgh / PH Dept, CERN
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Dr Andy Buckley, Royal Society University Research Fellow
>>> Particle Physics Expt Group, University of Edinburgh / PH Dept, CERN
>>> _______________________________________________
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org
>>> http://www.hepforge.org/lists/listinfo/rivet
>> 
> 
> 
> -- 
> Dr Andy Buckley, Royal Society University Research Fellow
> Particle Physics Expt Group, University of Edinburgh / PH Dept, CERN