Hi

On Mon, Dec 10, 2007 at 08:27:31PM -0700, Martin Michlmayr wrote:
> Package: passepartout
> Version: 0.7.0-1
> Usertags: ftbfs-gcc-4.3
> 
> Your package fails to build with GCC 4.3.  Version 4.3 has not been
> released yet but I'm building with a snapshot in order to find errors
> and give people an advance warning.  In GCC 4.3, the C++ header
> dependencies have been cleaned up.  The advantage of this is that
> programs will compile faster.  The downside is that you actually
> need to directly #include everything you use (but you really should
> do this anyway, otherwise your program won't work with any compiler
> other than GCC).  There's some more information about this at
> http://www.cyrius.com/journal/2007/05/10#gcc-4.3-include
> 
> You can reproduce this problem with gcc-snapshot from unstable.  Note
> that Red Hat, Novell and Ubuntu have done some work getting packages
> to build with GCC 4.3 so there might be patches floating around
> somewhere.  I suggest you talk to your upstream.
> 
> > Automatic build of passepartout_0.7.0-1 on em64t by sbuild/amd64 0.53
> ...
> > stringutil.cc:80: warning: deprecated conversion from string constant to 
> > 'char*'
> > stringutil.cc:80: warning: deprecated conversion from string constant to 
> > 'char*'
> > if x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../../src     
> > -I/usr/include/libxml++-1.0 -I/usr/lib/libxml++-1.0/include 
> > -I/usr/include/libxml2   -DPNG_NO_MMX_CODE -I/usr/include/gtkmm-2.4 
> > -I/usr/lib/gtkmm-2.4/include -I/usr/include/glibmm-2.4 
> > -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 
> > -I/usr/lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 
> > -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 -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 -I/usr/lib/gtk-2.0/include 
> > -I/usr/include/cairomm-1.0 -I/usr/include/pango-1.0 -I/usr/include/cairo 
> > -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/atk-1.0   
> > -DPNG_NO_MMX_CODE -I/usr/include/libgnomecanvasmm-2.6 
> > -I/usr/lib/libgnomecanvasmm-2.6/include -I/usr/include/gtkmm-2.4 
> > -I/usr/lib/gtkmm-2.4/include -I/usr/include/libgnomecanvas-2.0 
> > -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include 
> > -I/usr/include/gdkmm-2.4 -I/usr/lib/gdkmm-2.4/include 
> > -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 -I/usr/include/gtk-2.0 
> > -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 
> > -I/usr/lib/gtk-2.0/include -I/usr/include/cairomm-1.0 
> > -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 
> > -I/usr/include/libpng12 -I/usr/include/atk-1.0 -I/usr/include/gail-1.0 
> > -I/usr/include/libart-2.0   -MT filesys.o -MD -MP -MF ".deps/filesys.Tpo" 
> > -c -o filesys.o filesys.cc; \
> >     then mv -f ".deps/filesys.Tpo" ".deps/filesys.Po"; else rm -f 
> > ".deps/filesys.Tpo"; exit 1; fi
> > filesys.cc: In constructor 'ClibException::ClibException(const 
> > std::string&)':
> > filesys.cc:20: error: 'strerror' was not declared in this scope
> > filesys.cc: In function 'std::string expand_path(const std::string&)':
> > filesys.cc:89: error: 'realpath' was not declared in this scope
> > filesys.cc: In function 'std::string mkdtemp(const std::string&)':
> > filesys.cc:132: error: 'strcpy' was not declared in this scope
> > make[4]: *** [filesys.o] Error 1
> > make[4]: Leaving directory `/build/tbm/passepartout-0.7.0/src/util'
> > make[3]: *** [all-recursive] Error 1
> > make[3]: Leaving directory `/build/tbm/passepartout-0.7.0/src'
> > make[2]: *** [all] Error 2
> > make[2]: Leaving directory `/build/tbm/passepartout-0.7.0/src'
> > make[1]: *** [all-recursive] Error 1

I tried to fix this today, but quickly discovered that #456971 on
libsigc++-2.0-dev is blocking this further down the path. As I currently
don't have the time to fix libsigc++-2.0-dev as well I just subscribed
to #456971 and added a block. I will look into this again as soon as
#456971 is fixed.

What are the current NMU rules for this issue? Would an NMU for #456971
be acceptable atm?

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


Reply via email to