On Mon, Jan 30, 2012 at 9:27 AM, Roy Stogner <royst...@ices.utexas.edu> wrote: > >> .) We're getting the following linker error: >> >> Linking >> .../libmesh_git/contrib/lib/x86_64-apple-darwin10.8.0_opt/libfparser.dylib >> ld: duplicate symbol >> FunctionParserBase<double>::FunctionWrapper::FunctionWrapper()in >> fpoptimizer/optimize_main.x86_64-apple-darwin10.8.0.opt.o and >> fparser.x86_64-apple-darwin10.8.0.opt.o >> collect2: ld returned 1 exit status >> >> We're working on tracking this down now, I don't suppose you've seen >> this on your end yet? > > > No sign of it, but IIRC on Linux the linker just takes the first > instance of any duplicate symbols it finds that result from template > instantiations... > > Isn't something similar supposed to happen on Mac, though? How else > are you supposed to handle inlined template functions like a templated > class' constructor?
That sounds right... and on Mac we use this -flat_namespace option when linking (I thought) to enforce this behavior. This option is definitely passed through to the fparser link command, though, so I'm not sure why the error. Anyway, I think we've at least tracked the issue down to the macro FUNCTIONPARSER_INSTANTIATE_TYPES which appears in both fparser.cc and fpoptimizer/optimize_main.cc. If I comment out the macro from one of those files, fparser seems to link fine (no duplicate symbols). However I don't know what effect this will have on executables, testing that now... -- John ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
