Re: Problem building NAMD (multiple definitions)

From: Jim Phillips (jim_at_ks.uiuc.edu)
Date: Mon May 23 2011 - 17:57:27 CDT

OK, just remove the -static flags from arch/arch/Linux-x86-g++.arch and it
should work.

-Jim

On Mon, 23 May 2011, Miroslav Hodak wrote:

> On 05/23/2011 06:41 PM, Axel Kohlmeyer wrote:
>> On Mon, May 23, 2011 at 6:38 PM, Miroslav Hodak<hodak_at_chips.ncsu.edu>
>> wrote:
>>> Guys:
>>>
>>> I was careful to specify 32 bit version for both charm++ and NAMD, so I do
>>> not think that would be a problem.
>>>
>>> Axel's suggestion appears to be correct, it indeed appears to be a linker
>>> problem. But where can I specify options for the linker in NAMD?
>> i would suspect that something went astray in your charm++ compile.
>>
>> as jim suggested, i would try the charm++ tests first. if they have the
>> same problem, you'll have to check out the charm++ build and wrapper
>> scripts. only if this goes smoothly, you'll have to check your arch files
>> for NAMD.
>>
>> cheers,
>> axel.
> Axel,
>
> megatest builds and tests suggested in notes.txt work without a problem. The
> problem only appears at the final stage of NAMD build and that is why I think
> it might be the linker issue.
>
> Miro
>
>>> Thanks,
>>> Miro
>>>
>>> On 05/23/2011 06:12 PM, Axel Kohlmeyer wrote:
>>>> jim,
>>>>
>>>> On Mon, May 23, 2011 at 6:08 PM, Jim Phillips<jim_at_ks.uiuc.edu> wrote:
>>>>> Hi Miro,
>>>>>
>>>>> My first guess is that you're trying to build a 32-bit Charm++ with a
>>>>> 64-bit
>>>>> MPI and that you should be using mpi-linux-x86_64 instead.
>>>> ... or a consequence of enforced static linkage.
>>>>
>>>> recent versions of the linker on linux refuse to link
>>>> the same object twice unless it is identical. this doesn't
>>>> apply to shared objects, since they are fully resolved only
>>>> at runtime. -Wl,--allow-multiple-definition might help.
>>>>
>>>> --allow-multiple-definition
>>>> -z muldefs
>>>> Normally when a symbol is defined multiple times, the
>>>> linker will report a
>>>> fatal error. These options allow multiple definitions and
>>>> the first definition
>>>> will be used.
>>>>
>>>>
>>>> cheers,
>>>> axel.
>>>>
>>>>> Were you able to build and run tests/charm++/megatest?
>>>>>
>>>>> -Jim
>>>>>
>>>>>
>>>>> On Mon, 23 May 2011, Miroslav Hodak wrote:
>>>>>
>>>>>> Dear All,
>>>>>>
>>>>>> I have been struggling getting to build NAMD. I know that binaries are
>>>>>> provided, but I want to try NAMD with Plumed, which requires building
>>>>>> from source.
>>>>>>
>>>>>> My compilation actually goes pretty well, I follow instructions from
>>>>>> notes.txt, and it makes it through the NAMD compilation, but I receive
>>>>>> the following errors at the linking step:
>>>>>>
>>>>>> /usr/lib/libc.a(malloc.o):(.data+0x10): multiple definition of
>>>>>> `__libc_malloc_initialized'
>>>>>>
>>>>>>
>>>>>> .rootdir/charm-6.3.2/mpi-linux/bin/../lib/libmemory-default.o:(.data+0x10):
>>>>>> first defined here
>>>>>> /usr/lib/libc.a(malloc.o): In function `__malloc_check_init':
>>>>>> (.text+0x200): multiple definition of `__malloc_check_init'
>>>>>>
>>>>>>
>>>>>> .rootdir/charm-6.3.2/mpi-linux/bin/../lib/libmemory-default.o:/home/miro/src/NAMD_2.8b3_Source/charm-6.3.2/mpi-linux/tmp/memory-gnu-hooks.c:393:
>>>>>> first defined here
>>>>>> /usr/lib/libc.a(malloc.o): In function `free':
>>>>>> (.text+0x4b50): multiple definition of `free'
>>>>>>
>>>>>>
>>>>>> .rootdir/charm-6.3.2/mpi-linux/bin/../lib/libmemory-default.o:/home/miro/src/NAMD_2.8b3_Source/charm-6.3.2/mpi-linux/tmp/memory.c:601:
>>>>>> first defined here
>>>>>> /usr/lib/libc.a(malloc.o): In function `malloc':
>>>>>> (.text+0x4c10): multiple definition of `malloc'
>>>>>>
>>>>>>
>>>>>> .rootdir/charm-6.3.2/mpi-linux/bin/../lib/libmemory-default.o:/home/miro/src/NAMD_2.8b3_Source/charm-6.3.2/mpi-linux/tmp/memory.c:594:
>>>>>> first defined here
>>>>>> /usr/lib/libc.a(malloc.o): In function `realloc':
>>>>>> (.text+0x59a0): multiple definition of `realloc'
>>>>>>
>>>>>>
>>>>>> .rootdir/charm-6.3.2/mpi-linux/bin/../lib/libmemory-default.o:/home/miro/src/NAMD_2.8b3_Source/charm-6.3.2/mpi-linux/tmp/memory.c:620:
>>>>>> first defined here
>>>>>> collect2: ld returned 1 exit status
>>>>>>
>>>>>> I also get bunch of warning about static libraries (statically linked
>>>>>> applications requires at runtime the shared libraries from the glibc
>>>>>> version used for linking), but I assume that those are harmless and
>>>>>> error comes from multiple definitions anyways.
>>>>>>
>>>>>> The errors apparently come from CHARMM, it appears that these files
>>>>>> have
>>>>>> statically compiled standard system memory management libraries in
>>>>>> them.
>>>>>> I am not really sure how to solve this, I looked at charmm compile
>>>>>> option and I do not see anything relevant.
>>>>>>
>>>>>> Can somebody help?
>>>>>>
>>>>>> Thanks,
>>>>>> Miro
>>>>>>
>>>>
>>>
>>
>>
>

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:57:11 CST