GNOME Bugzilla – Bug 498438
gcc-4.3 build issue
Last modified: 2008-03-10 15:22:52 UTC
glibmm2.4 2.14.2 does't build with gcc-4.3 /bin/bash ../../libtool --tag=CXX --mode=compile /usr/lib/gcc-snapshot/bin/g++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"glibmm\" -I../../glib -I../../glib -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -Wall -O2 -Wno-long-long -c -o object.lo object.cc /usr/lib/gcc-snapshot/bin/g++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"glibmm\" -I../../glib -I../../glib -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -Wall -O2 -Wno-long-long -c object.cc -fPIC -DPIC -o .libs/object.o object.cc: In constructor 'Glib::ConstructParams::ConstructParams(const Glib::Class&, const char*, ...)': object.cc:110: error: 'memset' was not declared in this scope Including cstring fixed the issue
Created attachment 99388 [details] [review] fix build issue
Feel free to commit with a ChangeLog entry to trunk and gtkmm-2-14. Thanks.
Change commited to glibmm-2-14 and trunk 2007-11-20 Sebastien Bacher <seb128@ubuntu.com> * glib/glibmm/object.cc: fix build issue when using gcc4.3 (#498438)
The exact same build issue happens on Solaris with the latest Sun C++ compiler (from the Sun Workshop 12 bundle), but including <cstring> doesn't fix it there. To fix this issue on Solaris, it's necessary to include string.h. My guess is that string.h would fix it on Linux too, so perhaps that's worth considering?
Please do submit a patch so people can test it on Linux.
Created attachment 105601 [details] [review] include string.h
I guess it might be fixed by adding 'std::' prefix to all string.h function. <c*> headers should declare functions within namespace std, but it seems on Linux that's not mandatory, and I'm not sure if that's a bug.
Yes, except in this case, the memset call is coming from a glib macro G_VALUE_COLLECT(), so it's not possible to change the call to add std:: here. Isn't the proper fix here to include <string.h> in the gvaluecollect.h header so that everybody that uses that macro doesn't have to include string.h themselves?
(In reply to comment #8) > Yes, except in this case, the memset call is coming from a glib macro > G_VALUE_COLLECT(), so it's not possible to change the call to add std:: here. > > Isn't the proper fix here to include <string.h> in the gvaluecollect.h header > so that everybody that uses that macro doesn't have to include string.h > themselves? > In such case, one can use "using std::memset;" to bring specifically required functions into global namespace.
I have committed the patch in comment #6. If something else would be better then please reopen with a new patch.