4.9.0 tarballs available (for packagers)

[Rolf Eike Beer]

Am Montag 30 Juli 2012, 20:34:41 schrieb 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/decl
> arativeimports/locale/locale.h:24, from /home/users/arekm/rpm/BUILD/kde-
> runtime-4.9.0/build/plasma/declarativeimports/locale/../../../../plasma/decl
> arativeimports/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_au
> tomoc.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.

Yes, but it is nothing that would not match what I'm saying. The search order 
is implementation defined, so may search the local libraries of the project 
still before the global ones even if the include was dragged in from a global 
header. In fact _any_ order is still valid. Not that most of them make the 
slightest sense, but that's it. And it still doesn't mean it's not also a 
compiler bug, in terms of surprising behavior.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120730/d6910d0f/attachment.sig>