After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 93412 - gtkmm2 needs workaround on Mac OS 10.2
gtkmm2 needs workaround on Mac OS 10.2
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: build
2.0
Other Mac OS
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2002-09-16 16:37 UTC by Julian Missig
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Julian Missig 2002-09-16 16:37:43 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)
Comment 1 Murray Cumming 2002-09-19 08:58:18 UTC
That URL would be very helpful.
Comment 2 Murray Cumming 2002-10-02 10:11:14 UTC
Please respond.
Comment 3 Murray Cumming 2002-10-11 10:58:55 UTC
Please respond.
Comment 4 Julian Missig 2002-10-11 15:58:20 UTC
Sorry about that...

http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01466.html
Comment 5 F.J.Franklin 2002-10-21 14:25:50 UTC
glib/glibmm/ustring.cc needs to be compiled with -fno-inline
/me
Comment 6 Julian Missig 2002-10-22 07:46:08 UTC
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!
Comment 7 Murray Cumming 2002-10-22 22:38:07 UTC
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?
Comment 8 Murray Cumming 2002-11-01 10:56:28 UTC
Please respond.
Comment 9 Murray Cumming 2002-11-10 02:12:36 UTC
Please respond.
Comment 10 Julian Missig 2002-11-10 02:47:57 UTC
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.
Comment 11 Murray Cumming 2002-11-10 22:20:28 UTC
I repeat:
> Is it the same as the gcc bug? If not, why
> doesn't that gcc bug affect you?
Comment 12 Murray Cumming 2003-02-08 14:07:58 UTC
I wish someone would ask some Mac OS X C++ people about this.
Comment 13 Murray Cumming 2003-02-26 07:28:40 UTC
Has anyone discovered anything? Has anyone asked on a Mac newsgroup?
Comment 14 Murray Cumming 2003-04-01 17:52:42 UTC
I _so_ much want to announce that MacOS is a supported platform.
Comment 15 Julian Missig 2003-04-01 21:44:01 UTC
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.
Comment 16 Max Horn 2003-05-15 13:19:23 UTC
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.
Comment 17 Julian Missig 2003-05-15 18:08:11 UTC
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.
Comment 18 Julian Missig 2003-05-15 18:14:32 UTC
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.
Comment 19 Murray Cumming 2003-05-19 05:49:45 UTC
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?
Comment 20 Murray Cumming 2003-06-05 14:29:08 UTC
Max, could you respond please? I'd like to push this forward somehow.
Thanks.
Comment 21 Max Horn 2003-06-05 15:21:55 UTC
"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 :-)
Comment 22 Murray Cumming 2003-06-06 08:28:15 UTC
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.
Comment 23 Julian Missig 2003-06-29 03:54:47 UTC
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
Comment 24 Murray Cumming 2003-06-30 09:06:31 UTC
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.
Comment 25 Julian Missig 2003-07-01 00:25:17 UTC
Right, Apple patches their gcc a /lot/

How would I go about investigating this?
Comment 26 Murray Cumming 2003-07-01 06:38:36 UTC
> How would I go about investigating this?

Look at the source code and see if the error makes any sense?
Comment 27 Murray Cumming 2003-07-01 06:47:04 UTC
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.

Comment 28 Julian Missig 2003-07-01 21:03:44 UTC
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.
Comment 29 Julian Missig 2003-07-02 03:18:37 UTC
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)=($
Comment 30 Julian Missig 2003-07-02 19:22:45 UTC
Tried both with and without -Ddlsym=dlsym_prepend_underscore

Same problem.
Comment 31 Julian Missig 2003-07-09 03:25:19 UTC
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.
Comment 32 Julian Missig 2003-07-09 03:56:47 UTC
This is where I found that solution:
http://lists.apple.com/mhonarc/darwin-development/msg18546.html
Comment 33 Murray Cumming 2003-07-09 09:09:38 UTC
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.
Comment 34 Julian Missig 2003-07-09 14:27:12 UTC
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.
Comment 35 Murray Cumming 2003-07-12 15:40:20 UTC
As a start, you could make a note here of the versions that you are using.
Comment 36 Julian Missig 2003-07-12 16:25:47 UTC
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.
Comment 37 Murray Cumming 2003-07-13 13:47:58 UTC
But what libtool version? Or are you doing a simple configure;make 
without doing the whole autogen?
Comment 38 Julian Missig 2003-07-13 16:52:57 UTC
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)
Comment 39 Murray Cumming 2003-07-14 15:23:37 UTC
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.
Comment 40 Murray Cumming 2003-07-23 09:13:39 UTC
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.
Comment 41 Julian Missig 2003-08-05 18:18:20 UTC
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.
Comment 42 Murray Cumming 2003-08-06 07:23:45 UTC
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.
Comment 43 Julian Missig 2003-08-06 15:09:09 UTC
Well, without the patch I get the same error. :)
Comment 44 Murray Cumming 2003-08-07 12:44:51 UTC
Is that really the same patch that you used before?
Comment 45 Julian Missig 2003-08-10 02:11:07 UTC
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.
Comment 46 Julian Missig 2003-08-10 03:58:50 UTC
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_;
 };
Comment 47 Murray Cumming 2003-08-20 11:02:17 UTC
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.
Comment 48 Julian Missig 2003-08-20 15:42:48 UTC
I did file it back when I said "I'll file a report with Apple"
Comment 49 Murray Cumming 2003-08-20 16:16:01 UTC
Great? Do you have a URL or bug number for that?
Comment 50 Julian Missig 2003-08-20 23:08:20 UTC
No and no. Apple doesn't do that.
Comment 51 Murray Cumming 2003-10-23 10:07:23 UTC
Is there any chance of you writing a README.MacOSX for us?
Comment 52 Murray Cumming 2004-01-21 17:32:25 UTC
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.