GNOME Bugzilla – Bug 93412
gtkmm2 needs workaround on Mac OS 10.2
Last modified: 2004-12-22 21:47:04 UTC
Here's the error: ld: multiple definitions of symbol std::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign(char const*, unsigned long) ustring.lo definition of std::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign(char const*, unsigned long) in section (__TEXT,__text) /usr/lib/gcc/darwin/3.1/libstdc++.a(string-inst.o) private external definition of std::basic_string<char, std::char_traits<char>, std::allocator<char> >::assign(char const*, unsigned long) in section (__TEXT,__text) ld: multiple definitions of symbol std::basic_string<char, std::char_traits<char>, std::allocator<char> >::insert(unsigned long, char const*, unsigned long) ustring.lo definition of std::basic_string<char, std::char_traits<char>, std::allocator<char> >::insert(unsigned long, char const*, unsigned long) in section (__TEXT,__text) /usr/lib/gcc/darwin/3.1/libstdc++.a(string-inst.o) private external definition of std::basic_string<char, std::char_traits<char>, std::allocator<char> >::insert(unsigned long, char const*, unsigned long) in section (__TEXT,__text) ld: warning multiple definitions of symbol _locale_charset /sw/lib/libiconv.dylib(localcharset.lo) definition of _locale_charset /sw/lib/libintl.dylib(localcharset.lo) definition of _locale_charset /usr/bin/libtool: internal link edit command failed make[5]: *** [libglibmm-1.3.la] Error 1 temas managed to find the gcc bug report which pertains to something very similar to this. I'll get the link and append it soon. $ gcc --version gcc (GCC) 3.1 20020420 (prerelease)
That URL would be very helpful.
Please respond.
Sorry about that... http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01466.html
glib/glibmm/ustring.cc needs to be compiled with -fno-inline /me
I manually compiled ustring.cc with -fno-inline and gtkmm2 appears to not only compile, but actually work! (On the small apps in the tests/ dir) Thanks!
We need some explanation of this -fno-inline thing. What does it do, and why is it necessary? Is it the same as the gcc bug? If not, why doesn't that gcc bug affect you? And lastly, is there something that you need us to do?
From me? All I know is that -fno-inline probably forces gcc to not compile some of the functions as inline... I don't know why it's needed or why it works, just that it does seem to work for me.
I repeat: > Is it the same as the gcc bug? If not, why > doesn't that gcc bug affect you?
I wish someone would ask some Mac OS X C++ people about this.
Has anyone discovered anything? Has anyone asked on a Mac newsgroup?
I _so_ much want to announce that MacOS is a supported platform.
I wish that were easy to do.. but the Fink people aren't even being very supportive of me trying to get gtk+ 2.2 working, let alone gtkmm2... I really wish I knew more about what the hell OS X does when it's linking, but I still don't completely understand it. I'll try some more in the coming weeks and see if I can get it to work. The Fink people seem to believe that gtk+ is hell on OS X to begin with... I think I should try removing Fink and doing it all manually to see if they're just being KDE enthusiasts or if that's really the case. I can't seem to find much info about gtk2 on OS X.
Just to clarify something here. The Fink project (I am one of its three project leads) is not an "official" entity - Apple does not sponsor us in any way. We are all volunteers. It's not as if we are required to port anything. I am very astonished by Julian's claims about how we blockade him. The fact that we don't put our scarce resources, consisting of volunteers who port stuff to Mac OS X, into this, can hardly be attributed negatively to us. gtkmm2 has its problems working here, but that's in no way Fink's fault.
The person in charge of the Fink gtk package made it clear to me that gtk 2.2 is hell on OS X and that I should probably just try using Qt if I wanted a unix app to run on Fink. I don't think I unfairly represented that in my comment, but I'm sorry I sounded harsh--I was kind of mad at what he said. Nor did I say that Fink is in any way official or is in any way required to port anything--Fink is just the only means I currently have to try to figure out how to get this stuff working. I said that Fink people aren't being very supportive of me trying to get gtk 2.2 working--which definitely was the case, at least among those in the IRC channel. I don't think I represented Fink as some sort of official entity or something which must port gtk 2.2. I just said that Fink people weren't helping me. And they weren't.
Also, Max, you were the only one who did try helping me, and it may very well have been after I posted that comment. You personally have been very willing to help me--it's just that when I mention gtk, no other Fink people seem to want to even help me understand the errors I get.
Thanks for any help we get from the Fink people. It's all appreciated, and not at all expected. Do apple put out new releases of their gcc port and/or linker tools occasionally? Is there a web page we can monitor for new releases? Then we could at least try with new releases. If this looks like a compiler bug, then where can we report it?
Max, could you respond please? I'd like to push this forward somehow. Thanks.
"Do apple put out new releases of their gcc port and/or linker tools occasionally?" Yes. The last major release of the dev tools was Dec 2002. The next one should be this month, on the WWDC (World Wide Developer Conference), when a new OS X version is expected (10.3) and new developer tools, besides many other things. "Is there a web page we can monitor for new releases? Then we could at least try with new releases." http://connect.apple.com requires a (free) registration, then you can download the latest Developer Tools CD (and many other things there), and you can check there for new dev tools. I believe they also automatically notify registered users via email when they release new developer tools. "If this looks like a compiler bug, then where can we report it?" https://bugreport.apple.com - this requires you to login, using the same (free) account as for connect.apple.com (just like one has to register for bugzilla :-)
Julian, could you please log a bug with Apple about this? If the developer tools are released so infrequently then it makes sense to tell them as soon as possible.
As of June 23, Apple has released gcc 3.3 for Mac OS 10.2. 10.3 will also include 3.3. Unfortunately.... In file included from ../../glib/glibmm/exception.h:25, from ../../glib/glibmm/error.h:28, from ../../glib/glibmm/convert.h:29, from convert.cc:3: ../../glib/glibmm/ustring.h:532: error: `template<class In, class ValueType = typename std::iterator_traits<_Iterator>::value_type> struct Glib::ustring::SequenceToString' is private ../../glib/glibmm/ustring.h:548: error: within this context ../../glib/glibmm/ustring.h:532: error: `template<class In, class ValueType = typename std::iterator_traits<_Iterator>::value_type> struct Glib::ustring::SequenceToString' is private ../../glib/glibmm/ustring.h:554: error: within this context ../../glib/glibmm/ustring.h:532: error: `template<class In, class ValueType = typename std::iterator_traits<_Iterator>::value_type> struct Glib::ustring::SequenceToString' is private ../../glib/glibmm/ustring.h:560: error: within this context ../../glib/glibmm/ustring.h:532: error: `template<class In, class ValueType = typename std::iterator_traits<_Iterator>::value_type> struct Glib::ustring::SequenceToString' is private ../../glib/glibmm/ustring.h:566: error: within this context make[5]: *** [convert.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2
I guess their 3.3 is not the same as other 3.3s. Could you investigate this? Maybe some friend declaration somewhere isn't working. If this is a compiler bug then let's try to report it.
Right, Apple patches their gcc a /lot/ How would I go about investigating this?
> How would I go about investigating this? Look at the source code and see if the error makes any sense?
However, This seems to be a gcc bug that should be fixed soon: http://lists.gnome.org/archives/gtkmm-list/2003-May/msg00159.html (Guys, unfortunately it has not actually been fixed yet.) See also: http://mail.gnome.org/archives/gtkmm-list/2003-May/msg00165.html (I think there is a workaround patch in there.) I think this should be reported to Apple.
Ok, I applied the patch that the debian packager is using, and so far gtkmm2 seems to be compiling ok! Thanks for the link. I'll update again when I have everything compiled and can try it out. I'll file a bug report with Apple.
Finally finished compiling.... (julian@skadi)=(window)=($ ./wheelbarrow dyld: wheelbarrow Undefined symbols: __ZNSs20_S_empty_rep_storageE __ZNSs4_Rep11_S_terminalE __ZNSt24__default_alloc_templateILb1ELi0EE12_S_force_newE __ZNSt24__default_alloc_templateILb1ELi0EE12_S_free_listE __ZNSt24__default_alloc_templateILb1ELi0EE22_S_node_allocator_lockE __ZTVN10__cxxabiv117__class_type_infoE __ZTVN10__cxxabiv120__si_class_type_infoE __ZTVN10__cxxabiv121__vmi_class_type_infoE ___cxa_pure_virtual ___gxx_personality_v0 __ZNKSt11logic_error4whatEv __ZNKSt13runtime_error4whatEv __ZNSs20_S_empty_rep_storageE __ZNSs4_Rep11_S_max_sizeE __ZNSs4_Rep11_S_terminalE __ZNSt24__default_alloc_templateILb1ELi0EE12_S_force_newE __ZNSt24__default_alloc_templateILb1ELi0EE12_S_free_listE __ZNSt24__default_alloc_templateILb1ELi0EE22_S_node_allocator_lockE __ZTVN10__cxxabiv117__class_type_infoE __ZTVN10__cxxabiv120__si_class_type_infoE __ZTVN10__cxxabiv121__vmi_class_type_infoE ___cxa_pure_virtual ___gxx_personality_v0 Trace/BPT trap (julian@skadi)=(window)=($
Tried both with and without -Ddlsym=dlsym_prepend_underscore Same problem.
LIBTOOOOOOOOOOOOOOOOL! *shakes fist* curse you, libtool! curse you and all your little friends! Oh, btw. If one changes the libtool script, on the line where it says CC="gcc" to read CC="g++", then everything's dandy. With the debian packager's patch, that is. Yes, I repeat: I now have gtkmm2 working on Mac OS X. Only took me like a year.
This is where I found that solution: http://lists.apple.com/mhonarc/darwin-development/msg18546.html
Use archives, archives to access that link. It doesn't say much more than what Julian tells us. Well done Julian. I'd like to see a URL to a libtool bug about this. Surely this would affect a very simple HelloWorld as well as gtkmm.
Well, it's only certain libtool versions.. and only certain libraries. So I have no idea where the problem originates. I'll start looking, though.
As a start, you could make a note here of the versions that you are using.
I'm using Mac OS X 10.2.6 with the gcc 3.3 upgrade, fink cvs, libsigc++-1.2.5, and gtkmm-2.2.3.
But what libtool version? Or are you doing a simple configure;make without doing the whole autogen?
I'm using configure, so it's your libtool. ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36)
Strange, I was sure that we used libtool 1.5 for gtkmm 2.2.3. You might try deleting those generated files and re-autogening with a newer libtool.
It would be nice if you could try this with gtkmm 2.2.5 which really should be using libtool 1.5 (I checked the version in the ltmain.sh script). Then I'd really like a README.MacOSX file so that I can close this bug triumphantly.
Even with the patch from Debian: http://pokey.css.washington.edu/debian/gtkmm/gtkmm2.0/gtkmm2.0_2.2.5-1.diff.gz I still get this: In file included from ../../glib/glibmm/exception.h:25, from ../../glib/glibmm/error.h:28, from ../../glib/glibmm/convert.h:29, from convert.cc:3: ../../glib/glibmm/ustring.h:532: error: `template<class In, class ValueType = typename std::iterator_traits<_Iterator>::value_type> struct Glib::ustring::SequenceToString' is private ../../glib/glibmm/ustring.h:548: error: within this context ../../glib/glibmm/ustring.h:532: error: `template<class In, class ValueType = typename std::iterator_traits<_Iterator>::value_type> struct Glib::ustring::SequenceToString' is private ../../glib/glibmm/ustring.h:554: error: within this context ../../glib/glibmm/ustring.h:532: error: `template<class In, class ValueType = typename std::iterator_traits<_Iterator>::value_type> struct Glib::ustring::SequenceToString' is private ../../glib/glibmm/ustring.h:560: error: within this context ../../glib/glibmm/ustring.h:532: error: `template<class In, class ValueType = typename std::iterator_traits<_Iterator>::value_type> struct Glib::ustring::SequenceToString' is private ../../glib/glibmm/ustring.h:566: error: within this context on gtkmm-2.2.5. As you'll see above, I got this before, but Debian's patch had fixed it.
I can not find any code changes in that patch. I strongly suggest that you do not use the massive build file changes in that patch.
Well, without the patch I get the same error. :)
Is that really the same patch that you used before?
Sorry, was moving. No, it's not the same patch. It's the latest patch the Debian maintainer has.. maybe he removed the workaround in the new version. I'll look at the older version of the patch.
Ok, it works. This is the piece (the only piece) of the older debian patch that I used: --- gtkmm2.0-2.2.3.orig/glib/glibmm/ustring.h +++ gtkmm2.0-2.2.3/glib/glibmm/ustring.h @@ -520,7 +520,11 @@ //! @} +#if __GNUC__ == 3 && __GNUC_MINOR__ == 3 && __GNUC_PATCHLEVEL__ == 0 +public: +#else private: +#endif #ifndef DOXYGEN_SHOULD_SKIP_THIS @@ -533,6 +537,9 @@ #endif /* DOXYGEN_SHOULD_SKIP_THIS */ +#if __GNUC__ == 3 && __GNUC_MINOR__ == 3 && __GNUC_PATCHLEVEL__ == 0 +private: +#endif std::string string_; };
So that bug should probably be submitted to apple (see above for advice from Max Horn). You can just point them to the fixed gcc bug. There should be a link to that here: http://lists.gnome.org/archives/gtkmm-list/2003-May/msg00159.html but the gnome servers seem to be down right now.
I did file it back when I said "I'll file a report with Apple"
Great? Do you have a URL or bug number for that?
No and no. Apple doesn't do that.
Is there any chance of you writing a README.MacOSX for us?
I'm closing this, because gtkmm is now in Fink, and therefore easily available on MacOS X. The remaining problems seem to be Apple gcc bugs and a libtool bug. Julian, I'm sure that the Fink maintainer thanks you for showing him how to build it. Thanks for making this happen.