From: John P. <jwp...@gm...> - 2012-01-30 16:01:14
|
Roy, There are a couple of issues with the fparser stuff on Mac OSX... .) Dependencies file. fparser Makefile does echo -n '' > .dep For some reason I cannot fathom, this puts a -n character onto the first line of the .dep file on a Mac system??? Anyway, the intent seems to be to blank out the .dep file, so replacing this with rm -f .dep touch .dep seems to do the trick. Also the "sed -i" command which ends the .dep target had a bug which I've fixed as well. .) After make/make clean, I've got the extrasrc/fp_opcode_add.inc file hanging around. Should we check this in (similar to extrasrc/fp_identifier_parser.inc) or is it supposed to be regenerated? If the latter, why is extrasrc/fp_identifier_parser.inc checked in? .) 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? -- John |
From: Roy S. <roy...@ic...> - 2012-01-30 16:27:19
|
On Mon, 30 Jan 2012, John Peterson wrote: > There are a couple of issues with the fparser stuff on Mac OSX... I was afraid something might crop up; I'd copied and pasted some of the special-case OSX code from another contrib Makefile but I'd only tested on Linux before committing. Apologies to anyone whose builds got screwed up; next time I've got a commit that large and dubious I'll stick it in a branch and get other testers before adding it to trunk. > .) Dependencies file. fparser Makefile does > > echo -n '' > .dep > > For some reason I cannot fathom, this puts a -n character onto the > first line of the .dep file on a Mac system??? Anyway, the intent > seems to be to blank out the .dep file, so replacing this with > > rm -f .dep > touch .dep > > seems to do the trick. Yeah; "echo -n" isn't POSIX standard, I believe. That was the correct fix. > Also the "sed -i" command which ends the .dep target had a bug which > I've fixed as well. Thanks. > .) After make/make clean, I've got the > > extrasrc/fp_opcode_add.inc > > file hanging around. Should we check this in (similar to > extrasrc/fp_identifier_parser.inc) or is it supposed to be > regenerated? If the latter, why is extrasrc/fp_identifier_parser.inc > checked in? IIRC fp_opcode_add.inc was in the distributed tarball, but ought to be regenerated, so I removed it from svn. I'll add it to "make clean" as well. fp_identifier_parser.inc is s similar situation that I didn't notice before; I'll svn remove it. > .) 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? --- Roy |
From: John P. <jwp...@gm...> - 2012-01-30 17:52:43
|
On Mon, Jan 30, 2012 at 9:27 AM, Roy Stogner <roy...@ic...> 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 |
From: John P. <jwp...@gm...> - 2012-01-30 21:48:52
|
On Mon, Jan 30, 2012 at 10:52 AM, John Peterson <jwp...@gm...> wrote: > > 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... Commenting out the macro causes undefined symbols in the executables, so the fix isn't going to be that easy. I can recreate the problem on the Mac fairly simply, and it kind of baffles me... seems like it might be a bug in apple's compilers? Basically all you have to do is create two .C files which both try to do explicit template instantiation and the linker gets confused: // ============================== foo.h #include <iostream> // Declaration of templated class. Will be instantiated in both // foo1.C and foo2.C to test whether this leads to linking errors. template <class T> class Foo { public: T t; void print() { std::cout << "t=" << t << std::endl; } }; // ============================== foo1.C #include "foo.h" // Explicit instantiation for int template class Foo<int>; // ============================== foo2.C #include "foo.h" // Explicit instantiation for int template class Foo<int>; g++ -c foo1.C -o foo1.o g++ -c foo2.C -o foo2.o g++ -dynamiclib -o foo.dylib foo1.o foo2.o ld: duplicate symbol Foo<int>::print() in foo2.o and foo1.o collect2: ld returned 1 exit status make: *** [foo.dylib] Error 1 I'm pretty sure multiple instantiations in different translation units are allowed by the standard... the linker should be able to sort them out. Is that not the case? The same code compiles just fine on linux. And yes, I've also tried linking on the Mac with all the various options like libmesh uses (-flat_namespace, etc.) and it doesn't seem to make any difference. -- John |
From: Roy S. <roy...@ic...> - 2012-01-30 21:52:49
|
On Mon, 30 Jan 2012, John Peterson wrote: > I'm pretty sure multiple instantiations in different translation units > are allowed by the standard... the linker should be able to sort them > out. I believe so. Otherwise everybody's code would break as soon as they tried to do a vector<MyClass> v; no? What happens when you instantiate implicitly by creating a variable? --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-01-30 21:59:15
|
> I'm pretty sure multiple instantiations in different translation units > are allowed by the standard... the linker should be able to sort them > out. > > Is that not the case? Thought so, then again isn't this the debacle that has helped get 'extern' into the new standard for template instantiation? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm |
From: Derek G. <fri...@gm...> - 2012-01-30 21:59:32
|
What's weird to me is that we have fparser working fine in MOOSE. What's different about our version? Is this something that Phillip (the intern who put in the function parsing stuff) solved when he put fparser into MOOSE or is this something that has happened in the interim? Derek On Jan 30, 2012, at 2:48 PM, John Peterson wrote: > On Mon, Jan 30, 2012 at 10:52 AM, John Peterson <jwp...@gm...> wrote: >> >> 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... > > Commenting out the macro causes undefined symbols in the executables, > so the fix isn't going to be that easy. > > I can recreate the problem on the Mac fairly simply, and it kind of > baffles me... seems like it might be a bug in apple's compilers? > > Basically all you have to do is create two .C files which both try to > do explicit template instantiation and the linker gets confused: > > > // ============================== foo.h > #include <iostream> > > // Declaration of templated class. Will be instantiated in both > // foo1.C and foo2.C to test whether this leads to linking errors. > template <class T> > class Foo > { > public: > T t; > void print() { std::cout << "t=" << t << std::endl; } > }; > > > > // ============================== foo1.C > #include "foo.h" > > // Explicit instantiation for int > template class Foo<int>; > > > > > // ============================== foo2.C > #include "foo.h" > > // Explicit instantiation for int > template class Foo<int>; > > > > > g++ -c foo1.C -o foo1.o > g++ -c foo2.C -o foo2.o > g++ -dynamiclib -o foo.dylib foo1.o foo2.o > ld: duplicate symbol Foo<int>::print() in foo2.o and foo1.o > collect2: ld returned 1 exit status > make: *** [foo.dylib] Error 1 > > > > I'm pretty sure multiple instantiations in different translation units > are allowed by the standard... the linker should be able to sort them > out. > > Is that not the case? > > The same code compiles just fine on linux. > > And yes, I've also tried linking on the Mac with all the various > options like libmesh uses (-flat_namespace, etc.) and it doesn't seem > to make any difference. > > -- > 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: John P. <jwp...@gm...> - 2012-01-30 22:07:34
|
On Mon, Jan 30, 2012 at 2:59 PM, Derek Gaston <fri...@gm...> wrote: > What's weird to me is that we have fparser working fine in MOOSE. What's different about our version? Is this something that Phillip (the intern who put in the function parsing stuff) solved when he put fparser into MOOSE or is this something that has happened in the interim? The version in MOOSE has the optimizer stuff turned off (see fpconfig.h). The entire optimize_main.cc file is #ifdef'd out in this case, therefore you don't get the duplicate macro call. Cody seems to remember them commenting out the optimizer stuff a ways back for some reason, but couldn't remember exactly what. Maybe this is it? -- John |
From: Derek G. <fri...@gm...> - 2012-01-30 22:17:54
|
That's possibly it. I remember that getting commented out myself… and it was definitely for a compile issue, but I can't remember if it was exactly this issue. Let me say this though: it doesn't need the optimizer stuff. I was just running benchmarks last night that heavily utilized FParser… and it doesn't even show up in profiling… like not even close. I propose just turning it off for now (or maybe just turning it off for macs). Derek On Jan 30, 2012, at 3:07 PM, John Peterson wrote: > On Mon, Jan 30, 2012 at 2:59 PM, Derek Gaston <fri...@gm...> wrote: >> What's weird to me is that we have fparser working fine in MOOSE. What's different about our version? Is this something that Phillip (the intern who put in the function parsing stuff) solved when he put fparser into MOOSE or is this something that has happened in the interim? > > The version in MOOSE has the optimizer stuff turned off (see fpconfig.h). > > The entire optimize_main.cc file is #ifdef'd out in this case, > therefore you don't get the duplicate macro call. > > Cody seems to remember them commenting out the optimizer stuff a ways > back for some reason, but couldn't remember exactly what. Maybe this > is it? > > -- > John |
From: Roy S. <roy...@ic...> - 2012-01-30 22:28:15
|
On Mon, 30 Jan 2012, Derek Gaston wrote: > Let me say this though: it doesn't need the optimizer stuff. I was > just running benchmarks last night that heavily utilized FParser… > and it doesn't even show up in profiling… like not even close. I > propose just turning it off for now (or maybe just turning it off > for macs). Turning it off for OSX sounds like an ideal short-term solution to me; even turning it off altogether would be fine. --- Roy |