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 570648 - Wrong Code in glibmm causes build failtures for gtkmm and pangomm
Wrong Code in glibmm causes build failtures for gtkmm and pangomm
Status: RESOLVED INVALID
Product: glibmm
Classification: Bindings
Component: build
2.18.x
Other All
: Normal major
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2009-02-05 14:56 UTC by Bernd Buschinski
Modified: 2009-02-06 16:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
glibmm-2.4/glibmm/regex.h (29.74 KB, text/x-chdr)
2009-02-05 14:57 UTC, Bernd Buschinski
Details
glibmmconfig.h (3.01 KB, text/plain)
2009-02-05 21:54 UTC, Bernd Buschinski
Details
build.log (101.99 KB, text/plain)
2009-02-05 22:10 UTC, Bernd Buschinski
Details

Description Bernd Buschinski 2009-02-05 14:56:35 UTC
Please describe the problem:
pangomm fails for me because of

 x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"pangomm\" -I../../pango -I../../pango -I../../pango -I../../pango -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -march=amdfam10 -O2 -pipe -fomit-frame-pointer -MT color.lo -MD -MP -MF .deps/color.Tpo -c color.cc  -fPIC -DPIC -o .libs/color.o       
 x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -DG_LOG_DOMAIN=\"pangomm\" -I../../pango -I../../pango -I../../pango -I../../pango -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/cairomm-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -march=amdfam10 -O2 -pipe -fomit-frame-pointer -MT attrlist.lo -MD -MP -MF .deps/attrlist.Tpo -c attrlist.cc  -fPIC -DPIC -o .libs/attrlist.o                                                                                           
In file included from /usr/include/glibmm-2.4/glibmm.h:60,                                      
                 from ../../pango/pangomm/color.h:8,                                            
                 from color.cc:5:                                                               
/usr/include/glibmm-2.4/glibmm/regex.h:273: error: default argument missing for parameter 4 of 'static Glib::RefPtr<Glib::Regex> Glib::Regex::create(const Glib::ustring&, Glib::RegexCompileFlags, Glib::RegexMatchFlags, std::auto_ptr<Glib::Error>&)' 


As the compiler says the 4th default parameter is missing in
/usr/include/glibmm-2.4/glibmm/regex.h:273

The code if GLIBMM_EXCEPTIONS_ENABLED is not defined, but it doesnt change the fact that this code is plain wrong


static Glib::RefPtr<Glib::Regex> create(const Glib::ustring& pattern, RegexCompileFlags compile_options = static_cast<RegexCompileFlags>(0), RegexMatchFlags match_options = static_cast<RegexMatchFlags>(0), std::auto_ptr<Glib::Error>& error);

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
gcc-4.3.3

CBUILD="x86_64-pc-linux-gnu"                                                                    
CFLAGS="-march=amdfam10 -O2 -pipe -fomit-frame-pointer"                                         
CHOST="x86_64-pc-linux-gnu"
Comment 1 Bernd Buschinski 2009-02-05 14:57:07 UTC
Created attachment 128012 [details]
glibmm-2.4/glibmm/regex.h
Comment 2 Murray Cumming 2009-02-05 15:56:22 UTC
Thanks. I've corrected that in glibmm in svn trunk. Please confirm.

However, is there any particular reason that you are building with exceptions disabled? That's almost never worthwhile on a desktop machine. I certainly hope that you are not creating a distro package.
Comment 3 Bernd Buschinski 2009-02-05 21:54:23 UTC
Created attachment 128045 [details]
glibmmconfig.h

No, I am just hitting a bug, or at least that is what I think, where pangomm forgets the define but because it is enabled

grep EXCEPTIONS_ENABLED /usr/lib/glibmm-2.4/include/glibmmconfig.h
#define GLIBMM_EXCEPTIONS_ENABLED 1
  #define GLIBMM_EXCEPTIONS_ENABLED 1


If you have any clue why my pangomm forget the define an answer would be nice :)

pangomm compile fine with these changes
but without exception support
Comment 4 Bernd Buschinski 2009-02-05 22:10:15 UTC
Created attachment 128050 [details]
build.log

gtkmm also does not build because of the exception define
Comment 5 Murray Cumming 2009-02-06 07:45:53 UTC
Could you try adding some includes of glibmm/object.h or gtkmmconfig.h (or pangommconfig.h in pangomm) to see if that helps, please.

> pangomm compile fine with these changes but without exception support

Do you mean that you used the --enable-api-exceptions=no configure option?
Comment 6 Bernd Buschinski 2009-02-06 13:26:29 UTC
No with no extra options, so with exceptions enabled, but there is no --enable-api-exceptions=no is there?

But I found the cause for all this trouble, an old file witch was supposed to be a symlink to recent glibmmconfig.h, but it was a very old glibmmconfig.h copy, where no exceptions was defined.
But as the default arg thing is fixed in svn and pangomm compiles fine with it (with and without exceptions) this bug is fixed?
I dont want to look into gtkmm as there is no way to not have exceptions enabled, no configure option and so on, and gtkmm compiles fine with exceptions enabled, but if you really want to fix it, tell me, I may can test it again

Anyway I suggest this bug is fixed.
Comment 7 Murray Cumming 2009-02-06 13:50:33 UTC
The api configure options are on glibmm.

Yes, there doesn't seem to be a real problem here, though it was nice that you caught an error in glibmm.

I'm guessing this was on LFS or gentoo or suchlike, right?
Comment 8 Bernd Buschinski 2009-02-06 16:34:58 UTC
Yeah Gentoo, but rather my fault then gentoos :)