Hi Ken, Nils et al, I arbitrarily cc the m-list to keep some more folks informed (and for this reason leave the context long and, untrimmed)
On Jun 10, 2013, at 9:58 AM, Kenneth Hoste wrote: > > On 08 Jun 2013, at 10:45, Nils Christian wrote: > >> Hi Fotis and Ken, >> >> On Fri, Jun 07 at 19:16 Fotis GEORGATOS wrote: >>> thanks for the feedback; need to dive into it >>> in order to understand who makes the -lpthread the default >>> (which well has its own merit under the context of easybuild). >> >>> But, can you place the new easyconfig for libsbml on the experimental repo, >>> along with the patch, so that Ken (cc'd) has a chance to glimpse on it? >> >> The pthread issue was not related to libsbml. This I discovered when >> running 'make check' for HMMER 3.1b1 (should also apply for earlier >> versions, but there was no runtest defined), which worked fine when >> compiling 'by hand', but not with easybuild. It turned out that the >> Makefile was not properly linking LIBS for the unit tests, which was >> only problematic when easybuilding. I provided a patch, both upstream >> and in the easyconfig recipy (for which I generated I pull request >> yesterday evening). >> >> In summary, HMMER 3.1b1 now builds fine including the tests, I only >> wondered why LIBS was set to include '-lpthread', which triggered the >> problem. > > EasyBuild sets it by default, because it's commonly needed. In some cases, it > may not be needed or even breaks things, that's true. > I've seen other builds break too just because $LIBS is set (to something, > doesn't matter what). I haven't looked at the details of -lpthread being enabled by default, but if it remains so it makes me think that libpthreads-stubs should be at least a default builddep, no? (need myself to dive deeper in the pthread API business) fyi. we were looking earlier at the following (and, off-topic, HPL-2004-209.pdf): http://stackoverflow.com/questions/2127797/gcc-significance-of-pthread-flag-when-compiling and the initial request for this thread is visible at the very end here. > I haven't looked at the PR yet, maybe later this week. > > >> >>> Ken, there is also question for the framework that arises out of this, >>> when a given software piece is extension of two things at the same time >>> (Perl, Python etc). Nothing of a hurry, just to swap info. >> >> I just uploaded the libsbml recipy to experimental >> (users/xaver42/libsbml-5.8.0-with-experimental-goolf-1.4.10.eb). Ken, >> the "problem" here is that this recipy should set all the "PATH"s for >> the different language bindings (PERL5LIB, PYTHONPATH, ...), similar to >> PerlModule's, PythonPackage's ... make_module_extra. >> >> This opens up two questions: >> >> 1. should one be able to set language specific environment variables >> from the easyconfig directly (without the need to provide an easyblock)? >> To me this seems to be a rather generic problem, which could be solved >> with something similar to modextravars, only that it should append to >> these. > > modextravars is actually sufficient for this, no? Do you want a dedicated > easyconfig parameter for this? And if so, why in particular? I thought modextravars can only do setenv, can it also do prepend-path etc? >> 2. should all the language bindings go into one modulefile? Or would it >> be better to split those up? In the latter case it would still make >> sense to only build the package once and then generate a modulefile for >> each language. For this I see two possibilities: >> - one easyconfig provides more than one modulefile >> - "empty" easyconfig: the easyconfig does not need any source, but only >> depends on the primary package and sets the appropriate variables > > I don't see the problem with making multiple language bindings go to the same > module file. > Well, expect that the languages they depend on should be listed as > dependencies, and since we traditionally mention the language+version in the > versionsuffix, you'd get something like: > libsml-1.2.3-goolf-1.4.10-Python-2.7.5-Perl-5.16.3 > > Not sure how big of an issue that is (I'm fine with it). We will have an elegant solution to this, thanks to: https://github.com/hpcugent/easybuild-easyconfigs/issues/274 biodeps default builddep versions would imply the other versions, too (akin to goolf/goalf and toolchains in general). > One easyconfig that provides more than one module is... new. And potentially > confusing (although we already have an easyconfig that doesn't provide a > module after a successful 'build'). That is very likely a need for either distinct easyconfigs or a hackathon discussion. regards, Fotis >> One last feature request: libsbml does not allow to run cmake from >> within the source directory. To create a separate build directory, Fotis >> helped me with some hacks (see sources, start_dir and the very last >> configopts addition). Since out-of-tree builds are a feature of cmake I >> think this should be supported by the generic CMakeMake block. > > That's a very good one, maybe it should even be the default... > > Can you open an issue for this (or even better, a PR)? > > > regards, > > Kenneth > >> >> Have a nice weekend >> Nils >> >> >>> On Jun 7, 2013, at 5:02 PM, Nils Christian wrote: >>>> here a short summary of my findings so we don't forget about it: >> >>>> For some reason the environment variable LIBS contains '-lpthread' in >>>> the goolf and ictce toolchains. Therefore, a configure script created >>>> with ACX_PTHREAD in configure.ac will conclude >> >>>> "checking whether pthreads work without any flags": "yes" >> >>>> and stop checking. If LIBS would not contain the flag, configure would >>>> go on checking and finally set PTHREAD_CFLAGS="-pthread" (note the >>>> missing 'l'), which is usually merged with CFLAGS in Makefiles. >> >>>> At least in gcc this flags is different from the pure LIBS flag, as it >>>> also sets some preprocessor flags that influence how libraries are >>>> built. Why this may be important, see here: >>>> http://stackoverflow.com/questions/2127797/gcc-significance-of-pthread-flag-when-compiling >> >> -- >> Nils Christian >> Luxembourg Centre for Systems Biomedicine (LCSB) >> >> University Luxembourg >> Campus Belval >> 7, avenue des Hauts-Fourneaux >> L-4362 Esch-sur-Alzette >> >> email: [email protected] >> phone: +352 466644 6345 > -- Drs./Eng. Fotis Georgatos <[email protected]> HPC Systems Engineer, LCSB (University of Luxembourg) L-4362 Esch-sur-Alzette, Campus Belval, avenue des Hauts-Fourneaux 7 Phone: +352 466644 5609
