Re: Problem building NAMD (multiple definitions)

From: Miroslav Hodak (hodak_at_chips.ncsu.edu)
Date: Mon May 23 2011 - 17:49:59 CDT

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 : Mon Dec 31 2012 - 23:20:19 CST