Thanks for the explanation Mikael I can understand the reasoning. Looking
at the modules easybuild built for binutils it seems there are two versions
one which loads GCCcore and one that is standalone presumable for such
cases as you just described. Could the python module be changed to import
the binutils that load GCCcore rather than loading GCCcore?
On Fri, 19 Jul 2019 at 17:52, Mikael Öhman <micket...@gmail.com> wrote:
> So, GCCcore, the common ground for all software for both iccifort and GCC,
> is a bit special.
> There is some history here, older versions of iccifort that relied on the
> same GCCcore/6.4.0, but using different binutils.
>
> We've moved away from that, and haven't had any need to have multiple
> bintuils on the same GCCcore level, and both intel and foss uses the same
> binutils for each 201Xx release.
> But, perhaps, next CUDA or icc is going to have issues with certain linker
> versions, and maybe we'll have to select a different version. Not a super
> strong argument, and perhaps the others know of more compelling reasons for
> the current design. I suspect it's mostly a heritage.
>
>
>
>
> On Fri, Jul 19, 2019 at 9:40 PM Alastair Neil <ajneil.t...@gmail.com>
> wrote:
>
>> Thanks Jack
>>
>> With your suggestion I checked and yes only the GCCcore/8.2.0 module was
>> included by the Python/2.7.15-GCCcore-8.2.0 module - so no binutils.
>> Everything works if I load the binutils modules. To me it seems like a
>> strange choice not to load binutils along with the GCCcore I am struggling
>> to think of an example of when it would be necessary or desirable not to
>> have the accompanying binutils available. Am I missing something obvious?
>>
>> Mikael - thanks for the suggestions. I think option 1. is beyond my
>> skill set at the moment, but I will try option 2.
>>
>> Many Thanks,
>>
>> -Alastair
>>
>>
>> On Fri, 19 Jul 2019 at 14:05, Mikael Öhman <micket...@gmail.com> wrote:
>>
>>> Just to expand on what Jack wrote; these errors comes from trying to
>>> link code from a very new compiler with the (old) system ld.
>>>
>>> EasyConfigs have both build-dependencies, and (runtime) dependencies.
>>> When you load the module normally, you only get the latter. binutils is
>>> such a build-dep, but there are others as well (but probably nothing that
>>> specifically affects pycurl).
>>>
>>> Rather than using pip install directly, I would recommend you either
>>> 1. Create a new EasyConfig, and install it separately (using the
>>> PythonPackage easyblock)
>>> 2. Copy Python-2.7.15-GCCcore-8.2.0.eb, add pycurl to the list of
>>> extensions, and do a
>>> eb Python-2.7.15-GCCcore-8.2.0.eb --skip --rebuild
>>>
>>> (and then submit your work as a pull request on github)
>>>
>>> Best regards, Mikael
>>>
>>> On Fri, Jul 19, 2019 at 7:27 PM Alastair Neil <ajneil.t...@gmail.com>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> I am new to easybuild. I just installed version 3.9.3 on a centos
>>>> 7.6.1810 system. I first built the foss 2019a toolchain using:
>>>>
>>>> > eb foss-2019a.eb -r
>>>>>
>>>>
>>>> This completed with mo obvious issues. I then built python 2.7.15
>>>> using:
>>>>
>>>> > eb Python-2.7.15-GCCcore-8.2.0.eb -r
>>>>>
>>>>
>>>> This too seemed to complete without issue.
>>>>
>>>> I then tried to install a module using pip:
>>>>
>>>> > module load Python/2.7.15-GCCcore-8.2.0
>>>>> > pip -v install pycurl
>>>>>
>>>>
>>>> this dies with:
>>>>
>>>> Command
>>>>> "/opt/apps/easybuild/software/Python/2.7.15-GCCcore-8.2.0/bin/python -u -c
>>>>> "import setuptools,
>>>>> tokenize;__file__='/tmp/pip-install-mX9yps/pycurl/setup.py';f=getattr(tokenize,
>>>>> 'open', open)(__file__);code=f.read().replace('\r\n',
>>>>> '\n');f.close();exec(compile(code, __file__, 'exec'))" --with-openssl
>>>>> install --record /tmp/pip-record-Ui6qsC/install-record.txt
>>>>> --single-version-externally-managed --compile" failed with error code 1 in
>>>>> /tmp/pip-install-mX9yps/pycurl/
>>>>>
>>>>
>>>> The issue seems to be an assembler error:
>>>>
>>>> gcc -fno-strict-aliasing -O2 -ftree-vectorize -march=native
>>>>> -fno-math-errno -fPIC -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
>>>>> -fPIC -DPYCURL_VERSION="7.43.0.3" -DHAVE
>>>>> _CURL_SSL=1 -DHAVE_CURL_OPENSSL=1 -DHAVE_CURL_SSL=1
>>>>> -DHAVE_CURL_OPENSSL=1 -DHAVE_CURL_SSL=1
>>>>> -I/opt/apps/easybuild/software/Python/2.7.15-GCCcore-8.2.0/include/python2.7
>>>>> -c src/
>>>>> easy.c -o build/temp.linux-x86_64-2.7/src/easy.o
>>>>> /tmp/ccOJ03YM.s: Assembler messages:
>>>>> /tmp/ccOJ03YM.s:15: Error: unknown .loc sub-directive `view'
>>>>> /tmp/ccOJ03YM.s:15: Error: junk at end of line, first unrecognized
>>>>> character is `-'
>>>>> /tmp/ccOJ03YM.s:17: Error: unknown .loc sub-directive `view'
>>>>> /tmp/ccOJ03YM.s:17: Error: unknown pseudo-op: `.lvu1'
>>>>> /tmp/ccOJ03YM.s:20: Error: unknown .loc sub-directive `view'
>>>>> /tmp/ccOJ03YM.s:20: Error: unknown pseudo-op: `.lvu2'
>>>>> /tmp/ccOJ03YM.s:23: Error: unknown .loc sub-directive `view'
>>>>> /tmp/ccOJ03YM.s:23: Error: unknown pseudo-op: `.lvu3'
>>>>>
>>>> .... many more similar lines deleted....
>>>>>
>>>>
>>>> any pointers welcome as to how to resolve this.
>>>>
>>>> --Thanks
>>>>
>>>> Alastair
>>>>
>>>>
>>>>
>>>>
>>>>
