Re: [eigen] Link error: multiple definition of ei_p*** functions |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Link error: multiple definition of ei_p*** functions
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Thu, 17 Jun 2010 21:55:36 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=MPJ01/G24Y6Hw4K2dO1eSRD9R6EHSUYrThFjZV/Bej0=; b=VFNKQx0UfW97y0cPnqfcpIycPed1Ic7T5Cl67lRu3WO+NnxmjcfXq1PCxQgjx+G7zo GNkK4qx7cR2rydUL373UrF2QZhoT5CODhCAcpeg0NUMvARW71U3uCE5HXhncqgIm6XlZ vS6P7O/Y3pLZm80WFNMLC9E0hSonlgYfO07QY=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=BENugnDGzYF6CwVfvFMyAMcHBlE0bcM+4pA4YUVQvJUXOz88e01R6PV8Lit9G9s1Dp 8r99LlwfnRrWzi6UQ3VQkylffvsVH5zvnwlFTdjt/CJk5OhHAiQOtoKgEqe+jXYeKcXv SLp+mJY0h2lTFyfiTVZVj306VouDbgnr9gZ58=
at a first glance I thought this was a bit overkill, but finally
that's not too bad :) so let's go for it. and of course I also prefer
the "inline" solution.
gael
On Thu, Jun 17, 2010 at 7:36 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> Hi,
>
> Here's a patch fixing the issue.
>
> But it is not just fixing the issue, it is proposing a general solution.
>
> The problem of how to define functions in our headers without causing
> multiple definition linking errors, is one we've faced many times. We
> have had basically two approaches to work around it:
> - either make the function have static linkage. Big drawback: this
> means binary code bloat as the resulting executable may have N copies
> of the code of that function, if you linked together N object files.
> - or mark the function as inline. This fixes the issue nicely, but
> has the unwanted side effect of hinting the compiler toward inlining
> the function. Fortunately it's just a hint, so in cases where that
> would be a really bad idea, the compiler still won't inline it.
>
> Since there is no ideal solution, my diff introduces two new macros:
> #define EIGEN_DECLARE_FUNCTION_ALLOWING_MULTIPLE_DEFINITIONS
> #define EIGEN_DEFINE_FUNCTION_ALLOWING_MULTIPLE_DEFINITIONS inline
>
> see, the above values are for choosing the 'inline' approach, which I
> prefer. If you prefer the 'static' approach, set the 1st one to
> 'static' and the 2nd one to empty. The point of such macros is 1) to
> make our intent clear with these inline keywords, and 2) that if
> eventually a better solution appears, we can easily switch to it (even
> if it's not a drop-in replacement, these macros will be easy to search
> for).
>
> Opinions?
>
> Benoit
>
> 2010/6/16 Manoj Rajagopalan <rmanoj@xxxxxxxxx>:
>> Hi,
>>
>> I just began to notice these link errors in the "release" version of my code which I compile with SSE2 - multiple definitions of the
>> packet mathfunctions seem to be present in different .o files which is causing linker death. I just refreshed my working copy
>> before the build. Would someone know why this is happening? Perhaps some "inline" keyword is missing?
>>
>> My g++ command-line flags are as follows:
>>
>> -Wall -Werror -march=pentium4 -g0 -O3 -msse2 -mfpmath=sse
>> -ftree-vectorize -fgcse-sm -fgcse-las -fgcse-after-reload -fipa-pta
>> -ftree-loop-linear -ftree-loop-im -ftree-loop-ivcanon -ftracer -funroll-loops
>> -fvariable-expansion-in-unroller -fprefetch-loop-arrays -fno-math-errno
>> -ffinite-math-only -fno-trapping-math -fno-signaling-nans
>> -DEIGEN_NO_AUTOMATIC_RESIZING
>>
>>
>> A linker error log snippet is:
>>
>> kmesh.o: In function `float __vector Eigen::ei_psqrt<float __vector>(float __vector const&)':
>> kmesh.cpp:(.text+0x60): multiple definition of `float __vector Eigen::ei_psqrt<float __vector>(float __vector const&)'
>> iv.o:iv.cpp:(.text+0x60): first defined here
>> kmesh.o: In function `float __vector Eigen::ei_pcos<float __vector>(float __vector const&)':
>> kmesh.cpp:(.text+0xae): multiple definition of `float __vector Eigen::ei_pcos<float __vector>(float __vector const&)'
>> iv.o:iv.cpp:(.text+0x33ee): first defined here
>> kmesh.o: In function `float __vector Eigen::ei_psin<float __vector>(float __vector const&)':
>> kmesh.cpp:(.text+0x20e): multiple definition of `float __vector Eigen::ei_psin<float __vector>(float __vector const&)'
>> iv.o:iv.cpp:(.text+0x354e): first defined here
>> kmesh.o: In function `float __vector Eigen::ei_pexp<float __vector>(float __vector const&)':
>> kmesh.cpp:(.text+0x38c): multiple definition of `float __vector Eigen::ei_pexp<float __vector>(float __vector const&)'
>> iv.o:iv.cpp:(.text+0x36cc): first defined here
>> kmesh.o: In function `float __vector Eigen::ei_plog<float __vector>(float __vector const&)':
>> kmesh.cpp:(.text+0x4a2): multiple definition of `float __vector Eigen::ei_plog<float __vector>(float __vector const&)'
>> iv.o:iv.cpp:(.text+0x37e2): first defined here
>> offdiagfunctors.o: In function `float __vector Eigen::ei_psqrt<float __vector>(float __vector const&)':
>> offdiagfunctors.cpp:(.text+0x3e0): multiple definition of `float __vector Eigen::ei_psqrt<float __vector>(float __vector const&)'
>> iv.o:iv.cpp:(.text+0x60): first defined here
>> offdiagfunctors.o: In function `float __vector Eigen::ei_plog<float __vector>(float __vector const&)':
>> offdiagfunctors.cpp:(.text+0xb24): multiple definition of `float __vector Eigen::ei_plog<float __vector>(float __vector const&)'
>> iv.o:iv.cpp:(.text+0x37e2): first defined here
>>
>>
>> thanks,
>> Manoj
>>
>>
>>
>>
>