Discussion:
Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
Marek Polacek
2015-02-08 17:17:56 UTC
Permalink
To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek)
have performed a test mass rebuild of rawhide (January 15th package list)
using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from
the list packages that fail for non-GCC related reasons.

There were 16230 packages overall. 15303 packages built fine, 691 packages
failed to build with both gcc-5.0.0-0.5.fc22 and gcc-4.9.2-5.fc22 (ignored for
this analysis, unlikely to be GCC 5 related). That leaves us with 236 packages
that failed to build with GCC 5, but succeeded with GCC 4.9. These consist of
either package bugs, or GCC bugs. As things stand, just about 19 packages did
not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are fixed
at this time, and I promise I will fix the remaining one before long.

As usually, we will provide a "porting to" document to ease the transition to
the new GCC. This document is still in the works, yet it already contains
detailed description of the standard change for C; interested readers may visit
https://gcc.gnu.org/gcc-5/porting_to.html.

Main offender this time is probably the gnu11 change that entails different
inline semantics, enables some warnings by default, bumps the __STDC_VERSION__,
and so on. Hopefully it won't take too long till these packages catch on.
Many packages were not prepared for the new major version of GCC. There's also
been quite a lot of churn because of the preprocessor now emitting linemarkers
in the output when the -P option is not turned on. The C++ compiler now rejects
some code that it used to accept. Furthermore, GCC 5 has a batch of new warnings,
which, combined with -Werror, caused some additional failures.

The following is a more detailed list of what and why failed.

fcoe-utils-1.0.29-7.git9267509.fc22.src.rpm
gnome-disk-utility-3.14.0-1.fc22.src.rpm
lldpad-0.9.46-8.git48a5f38.fc22.src.rpm
udisks2-2.1.3-4.fc22.src.rpm
build failure due to -Werror; the -Wformat=2 option now enables
a new warning -Wformat-signedness, which warns about e.g.:
printf ("%d\n", 1U)
(%d expects argument of type int, but the argument has type
unsigned int).

dropwatch-1.4-10.fc22.src.rpm
build failure due to gnu11 change: glibc supports dynamic
allocation for string inputs via %a modifier, but in C99,
the %a modifier is a synonym for %f (float), so the compiler
expects an argument of type float *. The package should have
used the %m modifier, specified by POSIX.1-2008.

blktap-3.0.0-2.fc22.git0.9.2.src.rpm
cdrkit-1.1.11-26.fc22.src.rpm
cstream-3.1.1-3.fc22.src.rpm
dahdi-tools-2.10.0-2.fc22.src.rpm
dee-1.2.7-3.fc22.src.rpm
gdb-7.8.50.20150108-1.fc22.src.rpm
insight-7.8.50-2.20140827git.fc22.src.rpm
libomxil-bellagio-0.9.3-10.fc22.src.rpm
lmms-1.0.3-3.fc22.src.rpm
open-vm-tools-9.4.6-4.fc22.src.rpm
perl-Crypt-OpenSSL-X509-1.803-4.fc22.src.rpm
python-pyblock-0.53-8.fc22.src.rpm
sockperf-2.5.244-2.fc22.src.rpm
build failure due to -Werror; the new
-Wlogical-not-parentheses warning included in -Wall warns
(cases such as "if (!TYPE (t) == TYPE_FOO)").

glibc-2.20.90-17.fc22.src.rpm
build failure due to -Werror; -Waggressive-loop-optimizations
triggered during the testsuite run; this has already been fixed
upstream: https://sourceware.org/ml/libc-alpha/2015-01/msg00369.html

gtranslator-2.91.6-7.fc22.src.rpm
build failure due to -Werror; -Wmissing-include-dirs warning warns;
in 4.9 and earlier, the compiler ignored the -Werror option for
this warning, now it does not.

giada-0.7.0-5.fc22.src.rpm
build failure due to -Werror; -Wparentheses triggered; this warning
now works even in g++ on e.g.:
if (!i & 4)
...

ipv6calc-0.97.4-7.fc22.src.rpm
build failure due to -Werror; the new -Wsizeof-array-argument warns.
This warning detects e.g.:
int
foo (char a[8])
{
size_t s = sizeof (a);
...
}
where sizeof on the array function parameter will return a size of
char *, not a size of the array.

xen-4.4.1-12.fc22.src.rpm
build failure due to -Werror; -Wmaybe-uninitialized warns
about possibly uninitialized fields.

thewidgetfactory-0.2.1-20.fc22.src.rpm
build failure due to gnu11 change: missing declaration of strcmp.

tog-pegasus-2.13.0-19.fc22.src.rpm
build failure due to -Werror; here -Wunused-variable triggers
(unused const Uint32 PEGASUS_DYNAMIC_LEN(PEGASUS_DYNAMIC.size());
in a header file).

mongo-cxx-driver-1.0.0-0.7.rc3.fc22.src.rpm
build failure due to -Werror; the -Wunused-variable warning triggers

rcs-5.9.3-1.fc22.src.rpm
build failure due to wrong placement of _Noreturn, with -std=gnu89
it used __attribute__((__noreturn__)) instead, which is more flexible
in the placement (can go before or after the prototype, while
_Noreturn can only go before in function-specifiers).

argyllcms-1.6.3-4.fc22.src.rpm
libgphoto2-2.5.5.1-1.fc22.src.rpm
nogravity-2.00-22.fc22.src.rpm
these packages are not prepared for newer __STDC_VERSION__. Note
that with the gnu11 default __STDC_VERSION__ is defined to 201112L.
nogravity has:
#if !defined __STDC_VERSION__ || __STDC_VERSION__ < 199901L
...
#include <stdint.h>
...
and then
../../rlx32/src/v3xsoft.c:137:22: error: 'uintptr_t' undeclared

libgphoto2:
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
#define GP_LOG_DATA(DATA, SIZE) gp_log_data(__func__, DATA, SIZE)
#else
#define GP_LOG_DATA(DATA, SIZE) /* no-op */
then
gphoto2-port.c:390:2: error: called object is not a function or function pointer

argyllcms:
#if (__STDC_VERSION__ >= 199901L)
...
# define ATTRIBUTE_NORETURN __declspec(noreturn)
...
and then:
extern void ATTRIBUTE_NORETURN error(char *fmt, ...);
and that fails.

ekiga-4.0.1-15.fc22.src.rpm
opal-3.10.10-5.fc22.src.rpm
ptlib-2.10.10-8.fc22.src.rpm
these packages are trying to use <bits/atomicity.h>, but they should
use <ext/atomicity.h>. Probaby wrong __GNUC__ check.

firefox-35.0-1.fc22.src.rpm
icecat-31.2.0-6.fc22.src.rpm
kphotoalbum-4.5-4.fc22.src.rpm
thunderbird-lightning-3.3-5.fc22.src.rpm
these packages fail to build because they are trying to convert
std::nullptr_t to bool, and that requires direct-initialization.
The rules in C++11 have changed, cf.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1423
So:
bool b = nullptr; // wrong
bool b2(nullptr); // ok
These packages should simply have used false/true instead.

steghide-0.5.1-24.fc22.src.rpm
build failed because the package uses deprecated <hash_set>.

methane-1.5.1-9.fc21.src.rpm
build error because the C++ compiler in the C++11 mode started to reject
invalid code with narrowing conversion of constants within { }. (This
change was deliberate.)
For instance:
signed char a { __INT_MAX__ };
is accepted by g++ 4.9, but rejected by g++ 5.
see http://gcc.gnu.org/r213776

elk-2.3.22-10.fc22.src.rpm
ape-2.2.0-2.fc22.src.rpm
netcdf-fortran-4.4.1-1.fc22.src.rpm
build error because the packages try to load a Fortran module created by
a different version of GNU Fortran.

nodejs-mapnik-vector-tile-0.6.1-1.fc22.src.rpm
build failure due to wrong check of the GCC version; it uses C++11 features
without specifying -std=c++11 or -std=gnu++11.

ogre-1.9.0-5.fc22.src.rpm
it's unclear yet whether the code in the package is valid or not; g++ started
to reject the code since http://gcc.gnu.org/PR20332
The error message is "forming pointer to reference type".

odb-2.3.0-8.fc22.src.rpm
build failure because the gcc plugin API has changed.

DevIL-1.7.8-20.fc22.src.rpm
libhugetlbfs-2.18-4.fc22.src.rpm
ax25-tools-0.0.10-0.9.rc2.fc22.src.rpm
espresso-ab-1.0-8.fc22.src.rpm
build failure due to gnu11 change: "restrict" is a keyword, so you can't have
variables with such a name, e.g.
int i, restrict;
compiles in the C90 mode, but fails in the C99 mode.

bigloo-4.1a-6.2.fc22.src.rpm
memstomp-0.1.4-15.fc22.src.rpm
build failure due to gnu11 change: -Wimplicit-int is turned on by default now,
which is the reason these packages didn't compile properly. See the porting_to
document for more details.

libcmpiutil-0.5.7-4.fc22.src.rpm
nfs-ganesha-2.1.0-12.fc22.src.rpm
fvkbd-0.2.2-10.fc22.src.rpm
build failure due to gnu11 change that entails different inline semantics;
inline function declared but never defined. See the porting_to document for
more details.

libvpx-1.3.0-6.fc22.src.rpm
xemacs-21.5.34-8.20140605hgacf1c26e3019.fc22.src.rpm
build failure due to gnu11 change: these packages are defining theirs own
max_align_t type. But in C11, this type is already defined in <stddef.h>,
which is a conflict and thus the compile-time error. The same is true for
C++11.

ocaml-cil-1.7.3-14.fc22.src.rpm
build failure due to gnu11 change: during the %check phase, several warnings
that are now enabled by default trigger.

xarchon-0.50-17.fc22.src.rpm
xmms-speex-0.9.1-21.src.rpm
netdump-server-0.7.16-37.fc22.src.rpm
ssbd-0.10-12.fc22.src.rpm
gccxml-0.9.0-0.25.20140718.gitab651a2.fc22.src.rpm
ustr-1.0.4-18.fc22.src.rpm
xmms-1.2.11-22.20071117cvs.fc22.src.rpm
spacechart-0.9.5-14.fc22.src.rpm
xdialog-2.3.1-15.fc22.src.rpm
siril-0.8-19.fc22.src.rpm
soundtracker-0.6.8-20.fc22.src.rpm
ircd-ratbox-2.2.9-3.fc22.src.rpm
libglade-0.17-33.fc22.src.rpm
librep-0.92.4-1.fc22.src.rpm
bubblemon-1.46-17.fc22.src.rpm
gcx-0.9.11-17.fc22.src.rpm
libnetdude-0.11-11.fc22.src.rpm
ghc-network-2.4.1.2-32.fc21.src.rpm
hunt-1.5-20.fc22.src.rpm
koules-1.4-18.fc22.src.rpm
xmms-scrobbler-0.4.0-15.fc22.src.rpm
hfsplusutils-1.0.4-21.fc22.src.rpm
glib-1.2.10-43.fc22.src.rpm
svgalib-1.9.25-16.fc22.src.rpm
memtest86+-5.01-8.fc22.src.rpm
xmms-crossfade-0.3.14-10.fc22.src.rpm
xmms-arts-0.7.1-16.src.rpm
imlib-1.9.15-26.fc22.src.rpm
manedit-1.2.1-11.fc22.src.rpm
xmms-lirc-1.4-21.src.rpm
xconvers-0.8.3-15.fc22.src.rpm
bird-1.4.5-1.fc22.src.rpm
hugs98-2006.09-20.fc22.src.rpm
libstroke-0.5.1-31.fc22.src.rpm
gtk+-1.2.10-80.fc22.src.rpm
Io-language-20131204-1.fc22.src.rpm
mtd-utils-1.5.1-3.fc22.src.rpm
ORBit-0.5.17-40.fc22.src.rpm
build failure due to gnu11 change that entails different inline semantics;
the multiple definition error. See the porting_to document for more details.

fusecompress-2.6-24.20120812gita65cc33.fc22.src.rpm
pion-net-4.0.9-15.fc22.src.rpm
aqsis-1.8.2-13.fc22.src.rpm
shiny-0.3-8.git411ac43.fc22.src.rpm
adobe-source-libraries-1.0.43-23.fc22.src.rpm
lucene++-3.0.6-1.fc22.src.rpm
dmlite-0.7.2-1.fc22.src.rpm
ceph-0.87-1.fc22.src.rpm
boost-1.55.0-7.fc22.src.rpm
ompl-1.0.0-1.fc22.src.rpm
openttd-1.4.4-1.fc22.src.rpm
these packages failed because of errors such as the following:
error: no matching function for call to 'call_once(boost::once_flag&, void (*&)())'
The bug here was on the boost side I think, where boost code didn't cope with C++11
well, but it seems to be already fixed, thus these packages should build fine now.

shim-0.8-1.fc22.src.rpm
gummiboot-46-1.fc22.src.rpm
these packages failed to build, because they are using the -nostdinc option (don't
search header files in the standard directories), yet with gnu11 default they are
trying to include the <stdint.h> header.

cmocka-0.4.1-3.fc22.src.rpm
gmqcc-0.3.5-6.fc22.src.rpm
libssh-0.6.4-1.fc22.src.rpm
mirall-1.7.0-1.fc22.src.rpm
intrace-1.5-6.fc22.src.rpm
build error because of -pedantic-errors: gcc 5 has a new warning that warns
about GNU predefined identifiers, such as __FUNCTION__, if a -Wpedantic option
is specified. C99 supports the __func__ predefined identifier, so the packages
can use that, or add the __extension__ keyword where desirable.

llvm-3.5.0-6.fc22.src.rpm
this was a bug in LLVM sources; it's been already fixed in:
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/IntrusiveRefCntPtr.h?r1=218295&r2=218294&pathrev=218295

yap-6.2.2-12.fc22.src.rpm
a bug in the package - fails since http://gcc.gnu.org/PR59366
Here, a friend function template defined in a class was found without ADL.

undertaker-1.6.1-1.fc22.src.rpm
g++ has (wrongly) accepted an invalid code, this has been fixed by http://gcc.gnu.org/PR60463

python3-3.4.2-3.fc22.src.rpm
build started failing with http://gcc.gnu.org/PR60517
The code has an undefined behavior (returning address of a local variable); it
tried to perform a stack overflow, but the compiler turned the code via tail recursion
optimization into an endless loop.

cclive-0.9.3-4.fc22.src.rpm
cvc4-1.3-7.fc22.src.rpm
dans-gdal-scripts-0.23-5.fc22.src.rpm
emacs-24.4-3.fc22.src.rpm
ember-0.7.2-3.fc22.src.rpm
flamerobin-0.9.3-8.20130401snap.fc22.src.rpm
ghc-gtk-0.12.5.0-3.fc22.src.rpm
ghc-webkit-0.12.5.1-3.fc22.src.rpm
gnote-3.14.0-1.fc22.src.rpm
ksh-20120801-21.fc22.src.rpm
libason-0.1.2-2.fc22.src.rpm
libcmis-0.5.0-1.fc22.src.rpm
libgpg-error-1.16-1.fc22.src.rpm
libixion-0.7.0-3.fc22.src.rpm
liborcus-0.7.0-5.fc22.src.rpm
ncurses-5.9-17.20140906.fc22.src.rpm
openldap-2.4.40-5.fc22.src.rpm
perl-5.20.1-315.fc22.src.rpm
xorg-x11-server-1.16.2.901-1.fc22.src.rpm
xorg-x11-server-utils-7.7-10.fc22.src.rpm
zsh-5.0.7-4.fc22.src.rpm
these packages failed to build because of the changes in the preprocessor;
gcc started to generate line directives to better detect whether a macro
tokens come from a system header - see http://gcc.gnu.org/PR60723
The fix is to use the -P option if the code isn't prepared to deal with
such directives.

guitarix-0.32.0-1.fc22.src.rpm
gcc bug - libstdc++ had __attribute__((always_inline)) instead
of __always_inline__.
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/r220243

spatialindex-1.8.1-3.fc22.src.rpm
gcc bug - internal compiler error in devirtualization
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64538

abrt-java-connector-1.1.0-3.fc22.src.rpm
libldm-0.2.3-7.fc22.src.rpm
gcc bug - bogus -Wmissing-fields-initializers
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64709

telepathy-salut-0.8.1-7.fc22.src.rpm
gcc bug - a bug in byte swap optimizations
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64718

bash-4.3.33-1.fc22.src.rpm
openvpn-2.3.6-1.fc22.src.rpm
pymol-1.7.4-1.20141207svn4104.fc22.src.rpm
gcc bug - internal compiler error in the uninit pass
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64764

davix-0.4.0-1.fc22.src.rpm
gazebo-4.0.2-1.fc22.src.rpm
gmock-1.7.0-1.fc22.src.rpm
gtest-1.7.0-2.fc22.src.rpm
java-1.8.0-openjdk-1.8.0.40-19.b12.fc22.src.rpm
llvm34-3.4.2-5.fc22.src.rpm
redeclipse-1.4-8.fc22.src.rpm
gcc bug - wrong expansion of the __LINE__ macro
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64803

zorba-3.0.0-10.20140621git152f8964c.fc22.src.rpm
gcc bug - a wrong code issue
fixed upstream and in gcc-5.0.0-0.6.fc22, http://gcc.gnu.org/PR64853

criu-1.4-1.fc22.src.rpm
gcc bug - rejects valid code in C99 mode ([X ... Y] style initialization,
a GNU extension).
not fixed yet, http://gcc.gnu.org/PR64856

nntpgrab-0.7.2-9.fc22.src.rpm
gcc bug - a wrong code in FSM jump threading
a fix has been posted upstream, fixed in gcc-5.0.0-0.7.fc22
see http://gcc.gnu.org/PR64878

gnucap-0.35-14.fc22.src.rpm
gcc bug - wrong code due to bug in IPA propagation
fixed upstream and in gcc-5.0.0-0.7.fc22, http://gcc.gnu.org/PR64922

apron-0.9.10-23.fc22.src.rpm
L-function-1.23-12.fc22.src.rpm
mbox2eml-0.1.1-23.fc22.src.rpm
ppl-1.1-6.fc22.src.rpm
build error because g++ started to reject invalid code to reflect the
C++ DR217 (default arguments in function templates in redeclarations).
see http://gcc.gnu.org/PR15339

xiphos-4.0.0-3.fc22.src.rpm
this package failed to build because the limit of the instantiation depth
has been reached.

abook-0.6.0-0.15.20140116git5840fce.fc22.src.rpm
autofs-5.1.0-9.fc22.src.rpm
bandwidthd-2.0.1-27.fc22.src.rpm
bcache-tools-1.0.8-1.fc22.src.rpm
bfast-0.7.0a-10.fc22.src.rpm
bwm-ng-0.6-16.fc22.src.rpm
cdogs-sdl-0.4-14.fc22.src.rpm
covered-0.7.10-5.fc22.src.rpm
crm114-0-8.14.20100106.fc22.src.rpm
ebview-0.3.6.2-14.fc22.src.rpm
eggdrop-1.6.21-8.fc22.src.rpm
fbzx-2.10.0-5.fc22.src.rpm
garden-1.0.8-12.fc22.src.rpm
gcc-4.9.2-5.fc22.src.rpm
gfal2-2.7.8-3.fc22.src.rpm
gloox-1.0.10-4.fc22.src.rpm
gnaural-1.0.20110606-3.fc22.src.rpm
gnokii-0.6.31-10.fc22.src.rpm
gsmartcontrol-0.8.7-6.fc22.src.rpm
GtkAda-2.24.2-12.fc22.src.rpm
gtk+extra-2.1.2-15.fc22.src.rpm
isdn4k-utils-3.2-99.fc22.src.rpm
jack-audio-connection-kit-1.9.10-1.fc22.src.rpm
jfbterm-0.4.7-31.fc22.src.rpm
kmplayer-0.11.3c-7.fc22.src.rpm
libesedb-20120102-7.fc22.src.rpm
libewf-20140608-1.fc22.src.rpm
lpairs-1.0.4-14.fc22.src.rpm
mapserver-6.2.2-1.fc22.src.rpm
meterbridge-0.9.2-11.fc22.src.rpm
mingw-nsis-2.46-13.fc22.src.rpm
mirrormagic-2.0.2-16.fc22.src.rpm
mona-1.4r15-4.fc22.src.rpm
mono-2.10.8-7.fc21.src.rpm
muffin-2.4.2-1.fc22.src.rpm
nebula-0.2.3-10.fc22.src.rpm
oidentd-2.0.8-15.fc22.src.rpm
overgod-1.0-21.fc22.src.rpm
pads-1.2-16.fc22.src.rpm
php-pecl-memcache-3.0.8-6.fc22.src.rpm
python-dmidecode-3.10.13-12.fc22.src.rpm
qt-4.8.6-18.fc22.src.rpm
ratbox-services-1.2.1-11.fc21.src.rpm
reiserfs-utils-3.6.21-11.fc22.src.rpm
sblim-sfcb-1.4.9-1.fc22.src.rpm
sigar-1.6.5-0.12.git58097d9.fc22.src.rpm
sipsak-0.9.6-18.fc22.src.rpm
soundmodem-0.18-3.fc22.src.rpm
tcpick-0.2.1-24.fc22.src.rpm
teeworlds-0.6.3-1.fc22.src.rpm
trousers-0.3.13-3.fc22.src.rpm
udftools-1.0.0b3-28.fc22.src.rpm
unicornscan-0.4.7-9.fc22.src.rpm
vtun-3.0.3-11.fc22.src.rpm
weplab-0.1.5-15.fc22.src.rpm
wmmon-1.0-0.1.b2.20120606git575778a6.fc22.5.src.rpm
yad-0.27.0-1.fc22.src.rpm
build failure due to gnu11 change that entails different inline semantics;
an undefined reference to a function. See the porting_to document for more
details.

avarice-2.12-7.fc22.src.rpm
fawkes-0.5.0-19.fc22.src.rpm
fdm-1.7-5.fc22.src.rpm
libpuma-1.2-3.fc22.src.rpm
masscan-1.0.3-2.fc22.src.rpm
ncbi-blast+-2.2.30-1.fc22.src.rpm
nifti2dicom-0.4.9-1.fc22.src.rpm
ocp-0.1.20-9.fc22.2.src.rpm
root-5.34.24-1.fc22.src.rpm
trafficserver-5.0.1-1.fc22.src.rpm
uboot-tools-2015.01-0.2.rc3.fc22.src.rpm
vxl-1.17.0-15.fc22.src.rpm
webkitgtk-2.4.8-1.fc22.src.rpm
these packages are not prepared for gcc's version 5. E.g. fdm has:
ifeq ($(shell (LC_ALL=C $(CC) -v 2>&1|awk '/gcc version 4/') || true), )
CPPFLAGS:= -I. -I- $(CPPFLAGS)
else
CPPFLAGS:= -iquote. $(CPPFLAGS)
endif
but the gcc version is not 4 anymore -> the -iquote option isn't used,
so an error occurs later on.

HepMC-2.06.09-7.fc22.src.rpm
this one is not really clear, but the output of a program in the testsuite
was in a floating-point notation rather than in a decimal notation, hence
the test failed.

appstream-0.7.3-1.fc22.src.rpm
baloo-4.14.3-1.fc22.src.rpm
notmuch-0.19-1.fc22.src.rpm
perl-Search-Xapian-1.2.19.0-1.fc22.src.rpm
recoll-1.20.1-1.fc22.src.rpm
xapian-bindings-1.2.19-1.fc22.src.rpm
zeitgeist-0.9.16-0.3.20140808.git.ce9affa.fc22.src.rpm
these packages failed to build since they are using the Xapian library, which
has been built with gcc 4.9, but they expect it to be compiled with gcc 5.

Marek
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.o
Tom Hughes
2015-02-08 19:53:30 UTC
Permalink
Post by Marek Polacek
nodejs-mapnik-vector-tile-0.6.1-1.fc22.src.rpm
build failure due to wrong check of the GCC version; it uses C++11 features
without specifying -std=c++11 or -std=gnu++11.
I've patched this in Fedora and sent the patch upstream.

Tom
--
Tom Hughes (***@compton.nu)
http://compton.nu/
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of
Marek Polacek
2015-02-09 21:22:10 UTC
Permalink
Post by Marek Polacek
criu-1.4-1.fc22.src.rpm
gcc bug - rejects valid code in C99 mode ([X ... Y] style initialization,
a GNU extension).
not fixed yet, http://gcc.gnu.org/PR64856
Fixed upstream now.

Marek
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http:/
Jerry James
2015-02-09 21:43:25 UTC
Permalink
Post by Marek Polacek
bigloo-4.1a-6.2.fc22.src.rpm
memstomp-0.1.4-15.fc22.src.rpm
build failure due to gnu11 change: -Wimplicit-int is turned on by default now,
which is the reason these packages didn't compile properly. See the porting_to
document for more details.
The bigloo failure had nothing to do with -Wimplicit-int. One file
that should have been compiled with -fPIC wasn't. I don't know why
this didn't cause problems before. Fixed in Rawhide.
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.o
Marek Polacek
2015-02-10 05:22:04 UTC
Permalink
Post by Jerry James
Post by Marek Polacek
bigloo-4.1a-6.2.fc22.src.rpm
memstomp-0.1.4-15.fc22.src.rpm
build failure due to gnu11 change: -Wimplicit-int is turned on by default now,
which is the reason these packages didn't compile properly. See the porting_to
document for more details.
The bigloo failure had nothing to do with -Wimplicit-int. One file
that should have been compiled with -fPIC wasn't. I don't know why
this didn't cause problems before. Fixed in Rawhide.
IIRC bigloo contains various "autoconf" shell scripts with K&R code in
them (that fail with -Werror now) to detect e.g. -fpic. So that's why
the -fpic wasn't used.

Marek
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-con
Ralf Corsepius
2015-02-10 06:34:12 UTC
Permalink
Post by Marek Polacek
Post by Jerry James
Post by Marek Polacek
bigloo-4.1a-6.2.fc22.src.rpm
memstomp-0.1.4-15.fc22.src.rpm
build failure due to gnu11 change: -Wimplicit-int is turned on by default now,
which is the reason these packages didn't compile properly. See the porting_to
document for more details.
The bigloo failure had nothing to do with -Wimplicit-int. One file
that should have been compiled with -fPIC wasn't. I don't know why
this didn't cause problems before. Fixed in Rawhide.
IIRC bigloo contains various "autoconf" shell scripts with K&R code in
them (that fail with -Werror now)
Remove these -Werrors and tell upstream to not use -Werror.
-Werror turns harmless warnings into errors.

As autoconf scripts are based on compilers issuing errors only on real
errors and not on otherwise harmless warnings, -Werror is not useful
with autoconf scripts and is _guaranteed_ to break autoconf scripts,
because the items GCC warns about are changing with each GCC-release and
also depend on other factors (CFLAGS) in effect.

Ralf
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Con
Adam Jackson
2015-02-10 14:56:40 UTC
Permalink
Post by Ralf Corsepius
Post by Marek Polacek
Post by Jerry James
Post by Marek Polacek
bigloo-4.1a-6.2.fc22.src.rpm
memstomp-0.1.4-15.fc22.src.rpm
build failure due to gnu11 change: -Wimplicit-int is turned on by default now,
which is the reason these packages didn't compile properly. See the porting_to
document for more details.
The bigloo failure had nothing to do with -Wimplicit-int. One file
that should have been compiled with -fPIC wasn't. I don't know why
this didn't cause problems before. Fixed in Rawhide.
IIRC bigloo contains various "autoconf" shell scripts with K&R code in
them (that fail with -Werror now)
Remove these -Werrors and tell upstream to not use -Werror.
-Werror turns harmless warnings into errors.
As autoconf scripts are based on compilers issuing errors only on real
errors and not on otherwise harmless warnings, -Werror is not useful
with autoconf scripts and is _guaranteed_ to break autoconf scripts,
because the items GCC warns about are changing with each GCC-release and
also depend on other factors (CFLAGS) in effect.
If only there was some way to use different CFLAGS for configure than
for the project.

- ajax
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/co
Ralf Corsepius
2015-02-10 15:05:31 UTC
Permalink
Post by Adam Jackson
If only there was some way to use different CFLAGS for configure than
for the project.
Well, wouldn't you agree that developers should be able to read warnings
and filter out the serious one?

Ralf
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproje
Jakub Jelinek
2015-02-10 15:13:10 UTC
Permalink
Post by Adam Jackson
If only there was some way to use different CFLAGS for configure than
for the project.
Well, wouldn't you agree that developers should be able to read warnings and
filter out the serious one?
But -Werror automates that, at the cost that when compiler changes, grows
new warnings etc., you might need to adjust your code, and perhaps work
around false positive warnings or individually disable them.

Anyway, the problem was that K&R functions with implicit int etc.
are not valid in C99 or C11, and it would be desirable if developers from
time to time compared e.g. config.h files upon major compiler bumps if something
important didn't get turned off. Lots of failed configure tests will show
up somewhere during the build or in the testsuites, but some changes might
go unnoticed.

Jakub
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-o
Josh Stone
2015-02-10 17:49:21 UTC
Permalink
Post by Ralf Corsepius
Well, wouldn't you agree that developers should be able to read warnings
and filter out the serious one?
If a project has more than a screen-full of "harmless" warnings, then
it's very easy to miss when a serious one slips in. I prefer -Werror so
that nothing gets by, all warnings must be considered. It's not that
much of a burden after you first get to a warning-free build.

I could see the argument that this approach belongs in upstream
development, not so much distro packaging. I still think it's useful to
know that any patches applied are warning-free too though.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-cond
Jerry James
2015-02-10 16:07:52 UTC
Permalink
Post by Marek Polacek
IIRC bigloo contains various "autoconf" shell scripts with K&R code in
them (that fail with -Werror now) to detect e.g. -fpic. So that's why
the -fpic wasn't used.
Oh, I see. Thanks. I have sent an email upstream to inform them of
the nature of the problem. Regards,
--
Jerry James
http://www.jamezone.org/
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code
Matěj Cepl
2015-02-11 08:46:03 UTC
Permalink
Post by Marek Polacek
xiphos-4.0.0-3.fc22.src.rpm
this package failed to build because the limit of the
instantiation depth has been reached.
Upstream maintainers of Xiphos asked me whether there are some
build.logs for this available as obviously they have no
environment to reproduce this on their own.

Matěj
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/
Matej Stuchlik
2015-02-11 11:25:10 UTC
Permalink
Post by Marek Polacek
python3-3.4.2-3.fc22.src.rpm
build started failing with http://gcc.gnu.org/PR60517
The code has an undefined behavior (returning address of a local variable); it
tried to perform a stack overflow, but the compiler turned the code via tail recursion
optimization into an endless loop.
Would you have a buildlog of the failure available somewhere? I've tried to rebuild it [1]
and it seems to pass just fine.

Thanks,
Matt

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code o
Marek Polacek
2015-02-11 11:32:30 UTC
Permalink
Post by Matej Stuchlik
Post by Marek Polacek
python3-3.4.2-3.fc22.src.rpm
build started failing with http://gcc.gnu.org/PR60517
The code has an undefined behavior (returning address of a local variable); it
tried to perform a stack overflow, but the compiler turned the code via tail
recursion
optimization into an endless loop.
Would you have a buildlog of the failure available somewhere? I've tried to rebuild it [1]
and it seems to pass just fine.
You might want to look at http://bugs.python.org/issue23433, which
contains more information about this issue (and even a patch).

Marek
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedorapr
Jakub Jelinek
2015-02-11 11:53:18 UTC
Permalink
Post by Matej Stuchlik
Post by Marek Polacek
python3-3.4.2-3.fc22.src.rpm
build started failing with http://gcc.gnu.org/PR60517
The code has an undefined behavior (returning address of a local variable); it
tried to perform a stack overflow, but the compiler turned the code via tail
recursion
optimization into an endless loop.
Would you have a buildlog of the failure available somewhere? I've tried to rebuild it [1]
and it seems to pass just fine.
You've verified it rebuilt on i686. You've also got it stuck forever in
endless loop on x86_64 [1].
Post by Matej Stuchlik
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808
Jakub
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-co
Matej Stuchlik
2015-02-11 12:06:02 UTC
Permalink
----- Original Message -----
Sent: Wednesday, February 11, 2015 12:53:18 PM
Subject: Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
Post by Matej Stuchlik
Post by Marek Polacek
python3-3.4.2-3.fc22.src.rpm
build started failing with http://gcc.gnu.org/PR60517
The code has an undefined behavior (returning address of a local
variable);
it
tried to perform a stack overflow, but the compiler turned the code via tail
recursion
optimization into an endless loop.
Would you have a buildlog of the failure available somewhere? I've tried to
rebuild it [1]
and it seems to pass just fine.
You've verified it rebuilt on i686. You've also got it stuck forever in
endless loop on x86_64 [1].
Ow, my bad, I assumed it would pass on x86_64 as well. Thanks for pointing that out.
Post by Matej Stuchlik
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808
Jakub
--
devel mailing list
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http
Jan Synacek
2015-02-11 11:41:12 UTC
Permalink
Post by Marek Polacek
To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek)
have performed a test mass rebuild of rawhide (January 15th package list)
using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from
the list packages that fail for non-GCC related reasons.
...
openldap-2.4.40-5.fc22.src.rpm
Fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1191098
--
Jan Synacek
Software Engineer, Red Hat
David Tardon
2015-02-11 12:15:27 UTC
Permalink
Post by Marek Polacek
libixion-0.7.0-3.fc22.src.rpm
liborcus-0.7.0-5.fc22.src.rpm
Fixed.

D,
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedorap
Jakub Jelen
2015-02-11 13:58:25 UTC
Permalink
Post by Marek Polacek
To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek)
have performed a test mass rebuild of rawhide (January 15th package list)
using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from
the list packages that fail for non-GCC related reasons.
Looks like there are some new issues with gcc > 5.0.0-0.5.fc22 - my
package got through your rebuild (or was not mention in list), but I see
failures now in Koji or VM with gcc-5.0.0-0.10.fc22.x86_64 (koji) and
gcc-5.0.0-0.9.fc22.x86_64 (virtual machine).

Can somebody have a look at this issue (yes, this is update, but it
fails even with last git revision on fedorahosted which worked well with
gcc-4.9.2-5.fc22.x86_64 [1])? I wonder if there will be more people with
such problems.

Error message [2]:
/usr/bin/ld: ../libssh.a(sshkey.o): relocation R_X86_64_PC32 against
undefined symbol `stderr@@GLIBC_2.2.5' can not be used when making a
shared object; recompile with -fPIC

Best Regards,
Jakub

[1] Successful build:
http://koji.fedoraproject.org/koji/buildinfo?buildID=606983
[2] Failed build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8894851
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fe
Marek Polacek
2015-02-11 14:11:21 UTC
Permalink
Post by Marek Polacek
To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek)
have performed a test mass rebuild of rawhide (January 15th package list)
using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from
the list packages that fail for non-GCC related reasons.
Looks like there are some new issues with gcc > 5.0.0-0.5.fc22 - my package
got through your rebuild (or was not mention in list), but I see failures
now in Koji or VM with gcc-5.0.0-0.10.fc22.x86_64 (koji) and
gcc-5.0.0-0.9.fc22.x86_64 (virtual machine).
Can somebody have a look at this issue (yes, this is update, but it fails
even with last git revision on fedorahosted which worked well with
gcc-4.9.2-5.fc22.x86_64 [1])? I wonder if there will be more people with
such problems.
/usr/bin/ld: ../libssh.a(sshkey.o): relocation R_X86_64_PC32 against
object; recompile with -fPIC
Indeed, it looks like openssh passed with 5.0.0-0.5.fc22;
unfortunately I don't have the logs of the passed packages anymore.

I'd firstly take a look into diff between config.log with 4.9 and 5;
it sounds like some -fpic detection configure routine failed. Maybe
it passed the rebuild only by luck (?).

Marek
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproje
Jakub Jelen
2015-02-11 14:31:23 UTC
Permalink
Post by Marek Polacek
Post by Marek Polacek
To get some sense on how is GCC 5 standing, we (myself and Jakub Jelinek)
have performed a test mass rebuild of rawhide (January 15th package list)
using gcc-5.0.0-0.5.fc22 on x86_64, and for those packages that failed also
rebuilt the same package with gcc-4.9.2-5.fc22.x86_64 to quickly remove from
the list packages that fail for non-GCC related reasons.
Looks like there are some new issues with gcc > 5.0.0-0.5.fc22 - my package
got through your rebuild (or was not mention in list), but I see failures
now in Koji or VM with gcc-5.0.0-0.10.fc22.x86_64 (koji) and
gcc-5.0.0-0.9.fc22.x86_64 (virtual machine).
Can somebody have a look at this issue (yes, this is update, but it fails
even with last git revision on fedorahosted which worked well with
gcc-4.9.2-5.fc22.x86_64 [1])? I wonder if there will be more people with
such problems.
/usr/bin/ld: ../libssh.a(sshkey.o): relocation R_X86_64_PC32 against
object; recompile with -fPIC
Indeed, it looks like openssh passed with 5.0.0-0.5.fc22;
unfortunately I don't have the logs of the passed packages anymore.
I'd firstly take a look into diff between config.log with 4.9 and 5;
it sounds like some -fpic detection configure routine failed. Maybe
it passed the rebuild only by luck (?).
Marek
The only difference in configure (except some switched lines) in gcc 5.*
for these side configures missing:
-Wsign-compare -Wno-pointer-sign

Configure of ssh is the same (except the gcc version). Even the error
message looks quite strange - everything is build with -fPIC. I don't
think it was luck. Now the fail is quite deterministic.

Jakub
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code o
Jan Kratochvil
2015-02-11 15:07:33 UTC
Permalink
Post by Marek Polacek
gdb-7.8.50.20150108-1.fc22.src.rpm
Fixed/rebuilt, upstream not really affected.
http://pkgs.fedoraproject.org/cgit/gdb.git/commit/?id=5d84d7a16acc0469b6829f276987cf74e10ae848


Jan
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/
Dominik 'Rathann' Mierzejewski
2015-02-11 15:08:28 UTC
Permalink
On Sunday, 08 February 2015 at 18:17, Marek Polacek wrote:
[...]
Post by Marek Polacek
The following is a more detailed list of what and why failed.
abook-0.6.0-0.15.20140116git5840fce.fc22.src.rpm
Fixed.

Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
Frank Ch. Eigler
2015-02-11 18:43:26 UTC
Permalink
Post by Marek Polacek
To get some sense on how is GCC 5 standing, we (myself and Jakub
Jelinek) have performed a test mass rebuild of rawhide (January 15th
package list) using gcc-5.0.0-0.5.fc22 on x86_64 [...]
I'd like to bring to folks' attention one other scenario that can bite
with a gcc major version update. It's a more subtle failure, and it
might be widespread. In the case of pcp [1], it lets a build succeed,
but an opaque runtime error results.

In this case, the root cause was an autoconf fragment is used to
detect whether gcc supports -rdynamic:

cat <<End-of-File >conftest.c
main() {;}
End-of-File
rdynamic_flag=
$CC -o conftest -rdynamic conftest.c 2>conftest.out
test -s conftest.out || rdynamic_flag=-rdynamic

This used to succeed under gcc 4.9, but gcc 5 emits a warning

conftest.c:1:1: warning: return type defaults to `int' [-Wimplicit-int]
[...]

which the test takes as a failure due to its scanning of stderr. That
in turn nukes use of -rdynamic, which breaks -run-time- dlopen()
attempts between shared libraries.

Admittedly, it's not a great test (and we're fixing it upstream). But
it's possible that other programs' configury is similarly sensitive to
gcc warn-by-default changes, and result in a differently configured
build or even a broken runtime.


[1] https://kojipkgs.fedoraproject.org//packages/pcp/3.10.3/0.508.g8090873.fc22/data/logs/x86_64/build.log , search for -rdynamic


- FChE
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code
Michael Schwendt
2015-02-15 22:08:55 UTC
Permalink
Post by Marek Polacek
either package bugs, or GCC bugs. As things stand, just about 19 packages did
not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are fixed
at this time, and I promise I will fix the remaining one before long.
gcc-5.0.0-0.13.fc23 fails for Audacious 3.6-beta1 as tried in Copr:

https://copr.fedoraproject.org/coprs/mschwendt/audacious-next/build/72152/

As I haven't had a chance to look into it, Audacious upstream believes
it to be a C++ bug in GCC.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedorap
Jakub Jelinek
2015-02-15 22:14:33 UTC
Permalink
Post by Michael Schwendt
Post by Marek Polacek
either package bugs, or GCC bugs. As things stand, just about 19 packages did
not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are fixed
at this time, and I promise I will fix the remaining one before long.
https://copr.fedoraproject.org/coprs/mschwendt/audacious-next/build/72152/
As I haven't had a chance to look into it, Audacious upstream believes
it to be a C++ bug in GCC.
File a bugreport with preprocessed source?

Jakub
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Cod
Michael Schwendt
2015-02-16 14:10:55 UTC
Permalink
Post by Jakub Jelinek
Post by Michael Schwendt
Post by Marek Polacek
either package bugs, or GCC bugs. As things stand, just about 19 packages did
not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are fixed
at this time, and I promise I will fix the remaining one before long.
https://copr.fedoraproject.org/coprs/mschwendt/audacious-next/build/72152/
As I haven't had a chance to look into it, Audacious upstream believes
it to be a C++ bug in GCC.
File a bugreport with preprocessed source?
For that I would need a Rawhide installation and time to look into it
and the constexpr C++14 changes in GCC 5.

The same src.rpm builds fine on Fedora 21 (and also with Clang), so for a
constexpr expert it would be much easier to draw conclusions.
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct
Dave Johansen
2015-02-17 14:43:44 UTC
Permalink
Post by Marek Polacek
odb-2.3.0-8.fc22.src.rpm
build failure because the gcc plugin API has changed.
odb has been updated to 2.4.0 which supports the new gcc 5.0 plugin API,
but whenever I try to do the rebuild it fails to find libcutl (which I
rebuilt last night):
http://koji.fedoraproject.org/koji/taskinfo?taskID=8966447

Any ideas on what is going on there?
Frantisek Kluknavsky
2015-02-19 15:12:43 UTC
Permalink
Hi,

a list of things that usually break with each new gcc (like fortran
modules) would be nice to avoid a lot of pain with debugging. Does it
already exist?

WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2.8
(no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible
with 2.4,compatible with 2.6)" and it is checked at runtime. C++ ABI is
supposed to be unchanged in Fedora 22. This string changed anyway
because __GXX_ABI_VERSION in gcc changed. Is this expected/correct? Each
freshly rebuilt wx application will crash now. After wxGTK is rebuilt,
each old application will crash. A provenpackager should probably step in.

Have a nice day,

Fero
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-co
Jakub Jelinek
2015-02-19 15:15:09 UTC
Permalink
a list of things that usually break with each new gcc (like fortran modules)
would be nice to avoid a lot of pain with debugging. Does it already exist?
WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2.8 (no
debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with
2.4,compatible with 2.6)" and it is checked at runtime. C++ ABI is supposed
to be unchanged in Fedora 22. This string changed anyway because
__GXX_ABI_VERSION in gcc changed. Is this expected/correct? Each freshly
rebuilt wx application will crash now. After wxGTK is rebuilt, each old
application will crash. A provenpackager should probably step in.
That is a WxGTK bug. __GXX_ABI_VERSION can change, but usually the result
is still ABI compatible, g++ emits just some aliases when mangling has
changed.

Jakub
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code o
Orion Poplawski
2015-03-10 23:48:33 UTC
Permalink
Post by Jakub Jelinek
a list of things that usually break with each new gcc (like fortran modules)
would be nice to avoid a lot of pain with debugging. Does it already exist?
WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2.8 (no
debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with
2.4,compatible with 2.6)" and it is checked at runtime. C++ ABI is supposed
to be unchanged in Fedora 22. This string changed anyway because
__GXX_ABI_VERSION in gcc changed. Is this expected/correct? Each freshly
rebuilt wx application will crash now. After wxGTK is rebuilt, each old
application will crash. A provenpackager should probably step in.
That is a WxGTK bug. __GXX_ABI_VERSION can change, but usually the result
is still ABI compatible, g++ emits just some aliases when mangling has
changed.
Jakub
Could we please get this fixed? F22 is broken with this at the moment.

https://bugzilla.redhat.com/show_bug.cgi?id=1200611
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane ***@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http:/
Dan Horák
2015-03-12 16:13:04 UTC
Permalink
On Tue, 10 Mar 2015 17:48:33 -0600
Post by Orion Poplawski
Post by Jakub Jelinek
Post by Frantisek Kluknavsky
a list of things that usually break with each new gcc (like
fortran modules) would be nice to avoid a lot of pain with
debugging. Does it already exist?
WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying
"2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx
containers,compatible with 2.4,compatible with 2.6)" and it is
checked at runtime. C++ ABI is supposed to be unchanged in Fedora
22. This string changed anyway because __GXX_ABI_VERSION in gcc
changed. Is this expected/correct? Each freshly rebuilt wx
application will crash now. After wxGTK is rebuilt, each old
application will crash. A provenpackager should probably step in.
That is a WxGTK bug. __GXX_ABI_VERSION can change, but usually the
result is still ABI compatible, g++ emits just some aliases when
mangling has changed.
Jakub
Could we please get this fixed? F22 is broken with this at the moment.
https://bugzilla.redhat.com/show_bug.cgi?id=1200611
I'm looking on it now ...


Dan
--
devel mailing list
***@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedorapro
Loading...