4.9.0 tarballs available (for packagers)

[Michael Jansen]

On Monday, July 30, 2012 08:14:39 PM Rolf Eike Beer wrote:
> Am Montag 30 Juli 2012, 19:55:08 schrieb Albert Astals Cid:
> > El Diumenge, 29 de juliol de 2012, a les 10:57:01, Arkadiusz Miśkiewicz va
> > 
> > escriure:
> > > On Saturday 28 of July 2012, Arkadiusz Miśkiewicz wrote:
> > > > On Thursday 26 of July 2012, Albert Astals Cid wrote:
> > > > > The tarballs can be found in their usual embargo location (available
> > > > > only
> > > > > to packagers)
> > > > > 
> > > > > I'm attaching the sha1sum of the tarballs and the branches,
> > > > > hashes/revisions from which they have been created.
> > > > 
> > > > runtime tarball fails to build for me:
> > > Seems locale.h isn't best name to choose for local header since there is
> > > a
> > > system header with the same name that is commonly used. Renaming this
> > > file
> > > etc and problem is gone.
> > 
> > I agree the name is not the most optimal, but the code is correct
> > #include "locale.h"
> > has to include the locale.h of the local directory before looking for a
> > system wide one so i'm with Bartosz in blaming gcc or some other part of
> > the toolchain (moreover this file has been there since March 26 and noone
> > else seems to have complained until now).
> 
> I totally agree with you as this would be the only sane approach. But
> reality sucks.
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
> 
> See chapter 16.2, paragraph 2 and 3. And at least the MSVC compiler has ever
> ignored the ""-should-search-local-first.
> 
> Eike

You guys have it backwards i would say.

The problem seems to be that in line 44 of /usr/include/c++/<version>/clocale 
(#include <locale.h>) finds our file instead of the one from /usr/include/ 
(which includes one from /usr/include/bits with the same name).

In file included from /usr/include/c++/4.7.1/x86_64-pld-
linux/bits/c++locale.h:42:0,
                 from /usr/include/c++/4.7.1/bits/localefwd.h:42,
                 from /usr/include/c++/4.7.1/ios:42,
                 from /usr/include/c++/4.7.1/ostream:40,
                 from /usr/include/c++/4.7.1/iterator:64,
                 from /usr/include/qt4/QtCore/qiterator.h:46,
                 from /usr/include/qt4/QtCore/qlist.h:45,
                 from /usr/include/qt4/QtCore/qobject.h:50,
                 from /usr/include/qt4/QtCore/QObject:1,
                 from /home/users/arekm/rpm/BUILD/kde-
runtime-4.9.0/build/plasma/declarativeimports/locale/../../../../plasma/declarativeimports/locale/locale.h:24,
                 from /home/users/arekm/rpm/BUILD/kde-
runtime-4.9.0/build/plasma/declarativeimports/locale/../../../../plasma/declarativeimports/locale/calendarsystem.h:25,
                 from /home/users/arekm/rpm/BUILD/kde-
runtime-4.9.0/build/plasma/declarativeimports/locale/moc_calendarsystem.cpp:10,
                 from /home/users/arekm/rpm/BUILD/kde-
runtime-4.9.0/build/plasma/declarativeimports/locale/localebindingsplugin_automoc.cpp:4:
/usr/include/c++/4.7.1/clocale:55:11: error: ‘::lconv’ has not been declared
/usr/include/c++/4.7.1/clocale:56:11: error: ‘::setlocale’ has not been 
declared
/usr/include/c++/4.7.1/clocale:57:11: error: ‘::localeconv’ has not been 
declared

That is the only explanation i think for this error. So that local-first stuff 
is not the reason.

-- 
Michael Jansen
http://michael-jansen.biz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120730/85bde583/attachment.html>