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

[Andy Buckley]

On 23/07/13 17:27, James Monk wrote:
> 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.

Hmm, that's odd: I only started using that thing when I encountered the
CERN LCG Genser installation, which precisely does use those complicated
version + (mt) + compiler + ... name variations. There was no way that I
could work it out by hand, at least not without rewriting large chunks
of boost.m4. I didn't know that it needed a newer autoconf... sigh. I
agree it would be nice to not need bleeding edge libraries, but then the
HEP definition of a bleeding edge system is "less than 5 years old".

If you look in your config.log, you'll probably find loads of iterations
of boost.m4 trying to find the library with all those name variations.
I'm pretty sure it starts looking for the simplest name, so maybe
that'll tell you why it missed the obvious one on your machine.

Andy


> 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
> 
> 


-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Edinburgh / PH Dept, CERN