Re: Fedora mass rebuild 2017
On 07/02/17 22:32 +0100, Marek Polacek wrote: vegastrike-0.5.1-27.r1.fc24.src.rpm error: request for member ... in ... Looks like '.' is used instead of '->', so invalid C++. Reported upstream and fixed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 16 February 2017 at 07:02, Jonathan Wakely wrote:
> libffado has more of these stupid errors that have affected dozens of
> packages because [expletives deleted]:
>
> src/libieee1394/configrom.cpp: In member function 'bool
> ConfigRom::initialize()':
> src/libieee1394/configrom.cpp:179:31: error: ISO C++ forbids comparison
> between pointer and integer [-fpermissive]
> while ((buf + len - 1) == '\0') {
> ^~~~
> src/libieee1394/configrom.cpp:198:31: error: ISO C++ forbids comparison
> between pointer and integer [-fpermissive]
> while ((buf + len - 1) == '\0') {
> ^~~~
>
> That should probably be dereferencing (buf + len -1)
Yeah we got them fixed upstream. I see that you applied the fix and
rebuilt the package. Thank you for your work!
Orcan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 16.02.2017 13:02, Jonathan Wakely wrote:
On 16/02/17 10:15 +, Jonathan Wakely wrote:
On 15/02/17 22:53 -0500, Orcan Ogetbil wrote:
On 15 February 2017 at 09:12, Jonathan Wakely wrote:
A mockchain build of dbus-c++ libffado and sflphone works with this
patch. repoquery says nothing else depends on dbus-c++.
Any objections to me committing the patch to dbus-c++ and
rebuilding it?
Somebody should also fork dbus-c++ to fix or remove this junk.
Hi Jonathan,
Thank you for taking a look at this. I am fine with the patch. A less
intrusive solution would be to disable the #ifndef block between lines
232-235. But I am okay either way.
Let's do this the right way. I submitted a ticket on the project's
sourceforge tracker and I attached your patch.
https://sourceforge.net/p/dbus-cplusplus/patches/18/
Please feel free to apply your patch (adding a comment with a link to
the upstream ticket) and rebuild. We can update the package later if
upstream decides to act on it.
Will do, thanks for reporting it upstream.
I was wrong about the packages building with that patch. I was
confused by the fact that mockchain doesn't stop building if one
package in the chain fails, which makes it pretty useless.
libffado has more of these stupid errors that have affected dozens of
packages because [expletives deleted]:
src/libieee1394/configrom.cpp: In member function 'bool
ConfigRom::initialize()':
src/libieee1394/configrom.cpp:179:31: error: ISO C++ forbids
comparison between pointer and integer [-fpermissive]
while ((buf + len - 1) == '\0') {
^~~~
src/libieee1394/configrom.cpp:198:31: error: ISO C++ forbids
comparison between pointer and integer [-fpermissive]
while ((buf + len - 1) == '\0') {
^~~~
That should probably be dereferencing (buf + len -1)
And sflphone fails to configure now with some GnuTLS error, which
should be fixed by gnutls-3.5.9-2.fc26
sflphone is now failing for -Werror issues, looking into these. Thanks
for fixing dbus-c++.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 16/02/17 10:15 +, Jonathan Wakely wrote:
On 15/02/17 22:53 -0500, Orcan Ogetbil wrote:
On 15 February 2017 at 09:12, Jonathan Wakely wrote:
A mockchain build of dbus-c++ libffado and sflphone works with this
patch. repoquery says nothing else depends on dbus-c++.
Any objections to me committing the patch to dbus-c++ and rebuilding it?
Somebody should also fork dbus-c++ to fix or remove this junk.
Hi Jonathan,
Thank you for taking a look at this. I am fine with the patch. A less
intrusive solution would be to disable the #ifndef block between lines
232-235. But I am okay either way.
Let's do this the right way. I submitted a ticket on the project's
sourceforge tracker and I attached your patch.
https://sourceforge.net/p/dbus-cplusplus/patches/18/
Please feel free to apply your patch (adding a comment with a link to
the upstream ticket) and rebuild. We can update the package later if
upstream decides to act on it.
Will do, thanks for reporting it upstream.
I was wrong about the packages building with that patch. I was
confused by the fact that mockchain doesn't stop building if one
package in the chain fails, which makes it pretty useless.
libffado has more of these stupid errors that have affected dozens of
packages because [expletives deleted]:
src/libieee1394/configrom.cpp: In member function 'bool
ConfigRom::initialize()':
src/libieee1394/configrom.cpp:179:31: error: ISO C++ forbids comparison between
pointer and integer [-fpermissive]
while ((buf + len - 1) == '\0') {
^~~~
src/libieee1394/configrom.cpp:198:31: error: ISO C++ forbids comparison between
pointer and integer [-fpermissive]
while ((buf + len - 1) == '\0') {
^~~~
That should probably be dereferencing (buf + len -1)
And sflphone fails to configure now with some GnuTLS error, which
should be fixed by gnutls-3.5.9-2.fc26
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 15/02/17 22:53 -0500, Orcan Ogetbil wrote: On 15 February 2017 at 09:12, Jonathan Wakely wrote: A mockchain build of dbus-c++ libffado and sflphone works with this patch. repoquery says nothing else depends on dbus-c++. Any objections to me committing the patch to dbus-c++ and rebuilding it? Somebody should also fork dbus-c++ to fix or remove this junk. Hi Jonathan, Thank you for taking a look at this. I am fine with the patch. A less intrusive solution would be to disable the #ifndef block between lines 232-235. But I am okay either way. Let's do this the right way. I submitted a ticket on the project's sourceforge tracker and I attached your patch. https://sourceforge.net/p/dbus-cplusplus/patches/18/ Please feel free to apply your patch (adding a comment with a link to the upstream ticket) and rebuild. We can update the package later if upstream decides to act on it. Will do, thanks for reporting it upstream. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 15 February 2017 at 09:12, Jonathan Wakely wrote: > A mockchain build of dbus-c++ libffado and sflphone works with this > patch. repoquery says nothing else depends on dbus-c++. > > Any objections to me committing the patch to dbus-c++ and rebuilding it? > > Somebody should also fork dbus-c++ to fix or remove this junk. Hi Jonathan, Thank you for taking a look at this. I am fine with the patch. A less intrusive solution would be to disable the #ifndef block between lines 232-235. But I am okay either way. Let's do this the right way. I submitted a ticket on the project's sourceforge tracker and I attached your patch. https://sourceforge.net/p/dbus-cplusplus/patches/18/ Please feel free to apply your patch (adding a comment with a link to the upstream ticket) and rebuild. We can update the package later if upstream decides to act on it. Best, Orcan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 15/02/17 13:50 +, Jonathan Wakely wrote:
On 15/02/17 12:32 +, Jonathan Wakely wrote:
On 15/02/17 11:30 +, Jonathan Wakely wrote:
On 14/02/17 21:42 -0500, Orcan Ogetbil wrote:
On 7 February 2017 at 16:32, Marek Polacek wrote:
libffado-2.3.0-1.fc26.src.rpm
sflphone-1.4.1-20.fc26.src.rpm
error: no matching function for call to ...
Invalid code.
Nothing in dbus-c++ or libffado or sflphone uses the broken code in
dbus-c++ so it looks like it can just be commented out. See the
attached patch, which I'm testing now.
A mockchain build of dbus-c++ libffado and sflphone works with this
patch. repoquery says nothing else depends on dbus-c++.
Any objections to me committing the patch to dbus-c++ and rebuilding it?
Somebody should also fork dbus-c++ to fix or remove this junk.
diff --git a/dbus-c++-threading.patch b/dbus-c++-threading.patch
new file mode 100644
index 000..c4fafef
--- /dev/null
+++ b/dbus-c++-threading.patch
@@ -0,0 +1,45 @@
+--- libdbus-c++-0.9.0/include/dbus-c++/dispatcher.h.threading 2017-02-15
13:40:53.796004263 +
libdbus-c++-0.9.0/include/dbus-c++/dispatcher.h2017-02-15
13:40:46.907000493 +
+@@ -188,6 +188,7 @@
+ /* classes for multithreading support
+ */
+
++#if 0
+ class DXXAPI Mutex
+ {
+ public:
+@@ -243,9 +244,11 @@
+ typedef bool (*CondVarWaitTimeoutFn)(CondVar *cv, Mutex *mx, int timeout);
+ typedef void (*CondVarWakeOneFn)(CondVar *cv);
+ typedef void (*CondVarWakeAllFn)(CondVar *cv);
++#endif
+
+ void DXXAPI _init_threading();
+
++#if 0
+ void DXXAPI _init_threading(
+ MutexNewFn, MutexFreeFn, MutexLockFn, MutexUnlockFn,
+ CondVarNewFn, CondVarFreeFn, CondVarWaitFn, CondVarWaitTimeoutFn,
CondVarWakeOneFn, CondVarWakeAllFn
+@@ -312,6 +315,7 @@
+ cv->wake_all();
+ }
+ };
++#endif
+
+ } /* namespace DBus */
+
+--- libdbus-c++-0.9.0/src/dispatcher.cpp.threading 2017-02-15
13:48:22.627249868 +
libdbus-c++-0.9.0/src/dispatcher.cpp 2017-02-15 13:48:29.164253445
+
+@@ -253,6 +253,7 @@
+ #endif//DBUS_HAS_THREADS_INIT_DEFAULT
+ }
+
++#if 0
+ void DBus::_init_threading(
+ MutexNewFn m1,
+ MutexFreeFn m2,
+@@ -318,3 +319,4 @@
+ #endif//DBUS_HAS_RECURSIVE_MUTEX
+ dbus_threads_init(&functions);
+ }
++#endif
diff --git a/dbus-c++.spec b/dbus-c++.spec
index 21903f4..c7e83cf 100644
--- a/dbus-c++.spec
+++ b/dbus-c++.spec
@@ -1,6 +1,6 @@
Name: dbus-c++
Version: 0.9.0
-Release: 12%{?dist}
+Release: 13%{?dist}
Summary: Native C++ bindings for D-Bus
Group: System Environment/Libraries
@@ -13,6 +13,8 @@ Patch2: dbus-c++-linkfix.patch
# Fix collision between macro bind_property in dbus-c++/interface.h and method
# bind_property in glibmm/binding.h
Patch3: dbus-c++-macro_collision.patch
+# Remove broken classes for multithreading support
+Patch4: dbus-c++-threading.patch
BuildRequires: dbus-devel
BuildRequires: glib2-devel
@@ -56,6 +58,7 @@ sed -i 's/libtoolize --force --copy/libtoolize -if --copy/'
bootstrap
%patch1 -p1 -b .gcc47
%patch2 -p1 -b .linkfix
%patch3 -p1 -b .collision
+%patch4 -p1 -b .threading
%build
./autogen.sh
@@ -93,6 +96,9 @@ find $RPM_BUILD_ROOT -name '*.la' -exec rm -f {} ';'
%{_libdir}/pkgconfig/*
%changelog
+* Wed Feb 15 2017 Jonathan Wakely - 0.9.0-13
+- Remove broken multi-threading support that doesn't build with GCC 7
+
* Fri Feb 10 2017 Fedora Release Engineering -
0.9.0-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 15/02/17 12:32 +, Jonathan Wakely wrote:
On 15/02/17 11:30 +, Jonathan Wakely wrote:
On 14/02/17 21:42 -0500, Orcan Ogetbil wrote:
On 7 February 2017 at 16:32, Marek Polacek wrote:
libffado-2.3.0-1.fc26.src.rpm
sflphone-1.4.1-20.fc26.src.rpm
error: no matching function for call to ...
Invalid code.
I am 99% sure that these 2 errors are due to a bug in dbus-c++. Is the
new compiler attempting to compile (or verify) code in template
classes even if they are not initialized?
Yes, exactly. Previously GCC was fairly forgiving about broken
template code and would check almost nothing until the template was
instantiated. In more recent releases parts of the template which
don't depend on the template arguments get checked earlier. Clang has
been doing this for some time, but it's a more recent change for GCC.
I suspect that there is
broken code in the Threading class.
The standard says such code is ill-formed, but that no diagnostic is
required i.e. the compiler is allowed to diagnose the problem, but not
required to (because it could be expensive or difficult to check for
some compilers). So the code was always broken, but now GCC tells you
about it.
log:
-
usr/include/dbus-c++-1/dbus-c++/dispatcher.h:262:5: error: no matching
function for call to '_init_threading(DBus::Mutex* (&)(), void
(&)(DBus::Mutex*), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*),
DBus::CondVar* (&)(), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*, DBus::Mutex*), bool (&)(DBus::CondVar*,
DBus::Mutex*, int), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*))'
);
^
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: candidate:
void DBus::_init_threading()
void DXXAPI _init_threading();
^~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note:
candidate expects 0 arguments, 10 provided
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: candidate:
void DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn,
DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn,
DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn,
DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn)
void DXXAPI _init_threading(
^~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note:
conversion of argument 3 would be ill-formed:
-
see:
http://dbus-cplusplus.sourceforge.net/dispatcher_8h_source.html
The types MutexLockFn and MutexFreeFn depend on a macro:
#ifndef DBUS_HAS_RECURSIVE_MUTEX
typedef bool (*MutexFreeFn)(Mutex *mx);
typedef bool (*MutexLockFn)(Mutex *mx);
#else
typedef void (*MutexFreeFn)(Mutex *mx);
typedef void (*MutexLockFn)(Mutex *mx);
#endif//DBUS_HAS_RECURSIVE_MUTEX
But the type of the functions passed to _init_threading is always the
same:
static void mutex_free(Mutex *mx)
{
delete mx;
}
static void mutex_lock(Mutex *mx)
{
mx->lock();
}
That certainly looks suspicious.
More than suspicious. The DBus API docs at
https://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html
seem to say that the MutexFreeFn should always return void (for the
recursive and non-recursive versions) but it depends on
DBUS_HAS_RECURSIVE_MUTEX here. MutexUnlockFn should depend on
DBUS_HAS_RECURSIVE_MUTEX, but is always the same type here.
Worse, the functions in the C++ API return bool, but the functions in
the C API return dbus_bool_t which is a typedef for dbus_uint32_t, so
the types don't match and calling them is undefined.
It looks like dbus-c++ is abandoned though, the upstream repo was at
gitorious.org which is gone.
Nothing in dbus-c++ or libffado or sflphone uses the broken code in
dbus-c++ so it looks like it can just be commented out. See the
attached patch, which I'm testing now.
diff --git a/dbus-c++-threading.patch b/dbus-c++-threading.patch
new file mode 100644
index 000..c4fafef
--- /dev/null
+++ b/dbus-c++-threading.patch
@@ -0,0 +1,45 @@
+--- libdbus-c++-0.9.0/include/dbus-c++/dispatcher.h.threading 2017-02-15
13:40:53.796004263 +
libdbus-c++-0.9.0/include/dbus-c++/dispatcher.h2017-02-15
13:40:46.907000493 +
+@@ -188,6 +188,7 @@
+ /* classes for multithreading support
+ */
+
++#if 0
+ class DXXAPI Mutex
+ {
+ public:
+@@ -243,9 +244,11 @@
+ typedef bool (*CondVarWaitTimeoutFn)(CondVar *cv, Mutex *mx, int timeout);
+ typedef void (*CondVarWakeOneFn)(CondVar *cv);
+ typedef void (*CondVarWakeAllFn)(CondVar *cv);
++#endif
+
+ void DXXAPI _init_threading();
+
++#if 0
+ void DXXAPI _init_threading(
+ MutexNewFn, MutexFreeFn, MutexLockFn, MutexUnlockFn,
+ CondVarNewFn, CondVarFreeFn, CondVarWaitFn, CondVarWaitTimeoutFn,
CondVarWakeOneFn, CondVarWakeAllFn
+@@ -312,6 +315,7 @@
+ cv->wake_all();
+ }
+ };
++#endif
+
+ } /* namespace DBus */
+
+--- libdbus-c++-0.9.0/src/dispatcher.cpp.threading 2017-02-15
13:48:22.627249868 +
libdbus-c++-0.9.0/src/dispatcher.cpp 2017-02-15 13:48:29.164253445
+
+@@ -253,6 +253,7 @@
+ #endif//DBUS_HAS_THREADS_
Re: Fedora mass rebuild 2017
On 15/02/17 11:30 +, Jonathan Wakely wrote:
On 14/02/17 21:42 -0500, Orcan Ogetbil wrote:
On 7 February 2017 at 16:32, Marek Polacek wrote:
libffado-2.3.0-1.fc26.src.rpm
sflphone-1.4.1-20.fc26.src.rpm
error: no matching function for call to ...
Invalid code.
I am 99% sure that these 2 errors are due to a bug in dbus-c++. Is the
new compiler attempting to compile (or verify) code in template
classes even if they are not initialized?
Yes, exactly. Previously GCC was fairly forgiving about broken
template code and would check almost nothing until the template was
instantiated. In more recent releases parts of the template which
don't depend on the template arguments get checked earlier. Clang has
been doing this for some time, but it's a more recent change for GCC.
I suspect that there is
broken code in the Threading class.
The standard says such code is ill-formed, but that no diagnostic is
required i.e. the compiler is allowed to diagnose the problem, but not
required to (because it could be expensive or difficult to check for
some compilers). So the code was always broken, but now GCC tells you
about it.
log:
-
usr/include/dbus-c++-1/dbus-c++/dispatcher.h:262:5: error: no matching
function for call to '_init_threading(DBus::Mutex* (&)(), void
(&)(DBus::Mutex*), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*),
DBus::CondVar* (&)(), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*, DBus::Mutex*), bool (&)(DBus::CondVar*,
DBus::Mutex*, int), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*))'
);
^
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: candidate:
void DBus::_init_threading()
void DXXAPI _init_threading();
^~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note:
candidate expects 0 arguments, 10 provided
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: candidate:
void DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn,
DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn,
DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn,
DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn)
void DXXAPI _init_threading(
^~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note:
conversion of argument 3 would be ill-formed:
-
see:
http://dbus-cplusplus.sourceforge.net/dispatcher_8h_source.html
The types MutexLockFn and MutexFreeFn depend on a macro:
#ifndef DBUS_HAS_RECURSIVE_MUTEX
typedef bool (*MutexFreeFn)(Mutex *mx);
typedef bool (*MutexLockFn)(Mutex *mx);
#else
typedef void (*MutexFreeFn)(Mutex *mx);
typedef void (*MutexLockFn)(Mutex *mx);
#endif//DBUS_HAS_RECURSIVE_MUTEX
But the type of the functions passed to _init_threading is always the
same:
static void mutex_free(Mutex *mx)
{
delete mx;
}
static void mutex_lock(Mutex *mx)
{
mx->lock();
}
That certainly looks suspicious.
More than suspicious. The DBus API docs at
https://dbus.freedesktop.org/doc/api/html/group__DBusThreads.html
seem to say that the MutexFreeFn should always return void (for the
recursive and non-recursive versions) but it depends on
DBUS_HAS_RECURSIVE_MUTEX here. MutexUnlockFn should depend on
DBUS_HAS_RECURSIVE_MUTEX, but is always the same type here.
Worse, the functions in the C++ API return bool, but the functions in
the C API return dbus_bool_t which is a typedef for dbus_uint32_t, so
the types don't match and calling them is undefined.
It looks like dbus-c++ is abandoned though, the upstream repo was at
gitorious.org which is gone.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 14/02/17 21:42 -0500, Orcan Ogetbil wrote:
On 7 February 2017 at 16:32, Marek Polacek wrote:
libffado-2.3.0-1.fc26.src.rpm
sflphone-1.4.1-20.fc26.src.rpm
error: no matching function for call to ...
Invalid code.
I am 99% sure that these 2 errors are due to a bug in dbus-c++. Is the
new compiler attempting to compile (or verify) code in template
classes even if they are not initialized?
Yes, exactly. Previously GCC was fairly forgiving about broken
template code and would check almost nothing until the template was
instantiated. In more recent releases parts of the template which
don't depend on the template arguments get checked earlier. Clang has
been doing this for some time, but it's a more recent change for GCC.
I suspect that there is
broken code in the Threading class.
The standard says such code is ill-formed, but that no diagnostic is
required i.e. the compiler is allowed to diagnose the problem, but not
required to (because it could be expensive or difficult to check for
some compilers). So the code was always broken, but now GCC tells you
about it.
log:
-
usr/include/dbus-c++-1/dbus-c++/dispatcher.h:262:5: error: no matching
function for call to '_init_threading(DBus::Mutex* (&)(), void
(&)(DBus::Mutex*), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*),
DBus::CondVar* (&)(), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*, DBus::Mutex*), bool (&)(DBus::CondVar*,
DBus::Mutex*, int), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*))'
);
^
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: candidate:
void DBus::_init_threading()
void DXXAPI _init_threading();
^~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note:
candidate expects 0 arguments, 10 provided
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: candidate:
void DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn,
DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn,
DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn,
DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn)
void DXXAPI _init_threading(
^~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note:
conversion of argument 3 would be ill-formed:
-
see:
http://dbus-cplusplus.sourceforge.net/dispatcher_8h_source.html
The types MutexLockFn and MutexFreeFn depend on a macro:
#ifndef DBUS_HAS_RECURSIVE_MUTEX
typedef bool (*MutexFreeFn)(Mutex *mx);
typedef bool (*MutexLockFn)(Mutex *mx);
#else
typedef void (*MutexFreeFn)(Mutex *mx);
typedef void (*MutexLockFn)(Mutex *mx);
#endif//DBUS_HAS_RECURSIVE_MUTEX
But the type of the functions passed to _init_threading is always the
same:
static void mutex_free(Mutex *mx)
{
delete mx;
}
static void mutex_lock(Mutex *mx)
{
mx->lock();
}
That certainly looks suspicious.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On Tue, Feb 14, 2017 at 09:42:53PM -0500, Orcan Ogetbil wrote: > On 7 February 2017 at 16:32, Marek Polacek wrote: > > libffado-2.3.0-1.fc26.src.rpm > > sflphone-1.4.1-20.fc26.src.rpm > > error: no matching function for call to ... > > Invalid code. > > I am 99% sure that these 2 errors are due to a bug in dbus-c++. Is the > new compiler attempting to compile (or verify) code in template > classes even if they are not initialized? I suspect that there is > broken code in the Threading class. > > log: > - > usr/include/dbus-c++-1/dbus-c++/dispatcher.h:262:5: error: no matching > function for call to '_init_threading(DBus::Mutex* (&)(), void > (&)(DBus::Mutex*), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*), > DBus::CondVar* (&)(), void (&)(DBus::CondVar*), void > (&)(DBus::CondVar*, DBus::Mutex*), bool (&)(DBus::CondVar*, > DBus::Mutex*, int), void (&)(DBus::CondVar*), void > (&)(DBus::CondVar*))' > ); > ^ > /usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: candidate: > void DBus::_init_threading() > void DXXAPI _init_threading(); > ^~~ > /usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: > candidate expects 0 arguments, 10 provided > /usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: candidate: > void DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn, > DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn, > DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn, > DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn) > void DXXAPI _init_threading( > ^~~ > /usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: > conversion of argument 3 would be ill-formed: > - > > see: > http://dbus-cplusplus.sourceforge.net/dispatcher_8h_source.html I suppose this is another incarnation of what we described here: https://gcc.gnu.org/gcc-7/porting_to.html#hypothetical-instantiation Marek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 7 February 2017 at 16:32, Marek Polacek wrote: > libffado-2.3.0-1.fc26.src.rpm > sflphone-1.4.1-20.fc26.src.rpm > error: no matching function for call to ... > Invalid code. I am 99% sure that these 2 errors are due to a bug in dbus-c++. Is the new compiler attempting to compile (or verify) code in template classes even if they are not initialized? I suspect that there is broken code in the Threading class. log: - usr/include/dbus-c++-1/dbus-c++/dispatcher.h:262:5: error: no matching function for call to '_init_threading(DBus::Mutex* (&)(), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*), DBus::CondVar* (&)(), void (&)(DBus::CondVar*), void (&)(DBus::CondVar*, DBus::Mutex*), bool (&)(DBus::CondVar*, DBus::Mutex*, int), void (&)(DBus::CondVar*), void (&)(DBus::CondVar*))' ); ^ /usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: candidate: void DBus::_init_threading() void DXXAPI _init_threading(); ^~~ /usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: candidate expects 0 arguments, 10 provided /usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: candidate: void DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn, DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn, DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn, DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn) void DXXAPI _init_threading( ^~~ /usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: conversion of argument 3 would be ill-formed: - see: http://dbus-cplusplus.sourceforge.net/dispatcher_8h_source.html Best, Orcan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
Am Tue, 7 Feb 2017 22:32:09 +0100 schrieb Marek Polacek : > codeblocks-16.01-2.fc26.src.rpm ... > there are no arguments to .. that depend on a template > parameter, so a declaration of ... must be available > This code is ill-formed and G++ now rejects such code. Fixed and rebuild on F26. Jens pgpFO2jPUPYI4.pgp Description: Digitale Signatur von OpenPGP ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 08/02/17 13:11 +0100, Marek Skalický wrote: Marek Polacek píše v Út 07. 02. 2017 v 22:32 +0100: It's been a tradition now that every January we rebuild all the Fedora packages with the upcoming GCC, to reveal as many bugs as possible before we release the new version. This year is no different. There were 18811 packages overall (last year we had 17741 packages). 17263 built fine with the new GCC (mostly gcc-7.0.0-0.1.fc26.src.rpm but I also used a newer version from rawhide). 1350 failed with both GCC 6 and GCC 7, so I ignored these. This left us with ~198 packages that had to be analyzed, a number which, fortunately, was smaller than last year, when we'd had 577 FTBFS to investigate. MongoDB is not failing in your rebuild. However latest minor upgrade (v3.4.2) with gcc 7 is failing. I've figured out, that is optimization issue (with -O0 it is fine, with -01 it is failing) and it is ONLY ON ppc64le (other architectures are fine). I know which file is cause this issue, but I can't figure out with which optimization. I get what changes between O0 and O1 in output of 'gcc -O0/1 -Q --help=optimizers' and compiled with -O0 and flags of individual optimizations (which are added by O1), but failure does not appear. Because that doesn't work, see https://gcc.gnu.org/wiki/FAQ#optimization-options If you use -O0 then there is ***no*** optimization. At all. None. The optimizers aren't used, so it doesn't matter which optimizers you enable with -fxxx flags, none of them gets used. If you want to narrow down which flag causes the problem you need to enable optimization (so at least -O1 or -Os or -Og) and then disable individual optimizations. i.e. instead of starting with -O0 and adding -faaa and -fbbb, start with -O1 and use -fno-aaa and -fno-bbb. What else differs in -O1? How should I debug it? https://gcc.gnu.org/wiki/FAQ#misoptimization ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 08/02/17 08:42 +0100, Jakub Jelinek wrote:
On Tue, Feb 07, 2017 at 11:59:33PM +, Tom Hughes wrote:
On 07/02/17 23:56, Stephen John Smoogen wrote:
> On 7 February 2017 at 18:39, Sérgio Basto wrote:
> > Hi,
> > On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
> > > some C++ FE changes (especially the "Fix type-dependence
> > > and the current instantiation" changes made the compiler to reject
> > > invalid code
> > > that had previously been accepted, plus invalid conversions with '\0'
> > > are now
> > > rejected)
> >
> > Thanks for exhaustive explanation .
> > I have this case, how we fix ?
> > src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between
> > pointer and integer [-fpermissive]
> > if (pSlash != '\0') {
> >
>
> Someone would need to see more code than that. How is pSlash declared?
> What is the context of the code you have quoted?
Well I'm guessing it's a pointer to char and that should probably be:
if (*pSlash != '\0')
Yeah, or it can be also
if (pSlash != NULL)
or
if (pSlash)
etc.
It really depends on what the code is trying to do.
Yeah, a lot of "interesting" code I looked at was trying to check for
a null pointer by comparing to '\0' or was doing char* p = '\0' to
initialize a pointer to null.
Simply changing it to (*pSlash != '\0') would cause a segfault if that
pointer can be null and the code was trying to check for that case.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On Wed, Feb 08, 2017 at 01:11:32PM +0100, Marek Skalický wrote: > Marek Polacek píše v Út 07. 02. 2017 v 22:32 +0100: > > It's been a tradition now that every January we rebuild all the > > Fedora packages > > with the upcoming GCC, to reveal as many bugs as possible before we > > release > > the new version. This year is no different. > > > > There were 18811 packages overall (last year we had 17741 packages). > > 17263 built fine with the new GCC (mostly gcc-7.0.0-0.1.fc26.src.rpm > > but I also > > used a newer version from rawhide). 1350 failed with both GCC 6 and > > GCC 7, > > so I ignored these. This left us with ~198 packages that had to be > > analyzed, > > a number which, fortunately, was smaller than last year, when we'd > > had 577 FTBFS to > > investigate. > > MongoDB is not failing in your rebuild. However latest minor upgrade > (v3.4.2) with gcc 7 is failing. > I've figured out, that is optimization issue (with -O0 it is fine, with > -01 it is failing) and it is ONLY ON ppc64le (other architectures are > fine). The test mass rebuild has been performed on x86_64 only. > I know which file is cause this issue, but I can't figure out with > which optimization. I get what changes between O0 and O1 in output of > 'gcc -O0/1 -Q --help=optimizers' and compiled with -O0 and flags of > individual optimizations (which are added by O1), but failure does not > appear. > > What else differs in -O1? How should I debug it? Many things, and many things aren't even controlled by -f* switches, at -O0 most of the optimization passes are short-cut. I'd suggest try -fsanitize=undefined and/or -fsanitize=address to check if there aren't any obvious bugs in the code, if not, and e.g. -fno-inline -O1 still reproduces it, try to find which function is problematic (e.g. through addition of __attribute__((optimize (0))) to functions within the source and bisecting that way). If a single function is discovered, then one can often stub functions it calls and write main that calls that function with the right arguments to provide self-contained testcase. Or just file a rhbz with as many details as you can find. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
Marek Polacek píše v Út 07. 02. 2017 v 22:32 +0100: > It's been a tradition now that every January we rebuild all the > Fedora packages > with the upcoming GCC, to reveal as many bugs as possible before we > release > the new version. This year is no different. > > There were 18811 packages overall (last year we had 17741 packages). > 17263 built fine with the new GCC (mostly gcc-7.0.0-0.1.fc26.src.rpm > but I also > used a newer version from rawhide). 1350 failed with both GCC 6 and > GCC 7, > so I ignored these. This left us with ~198 packages that had to be > analyzed, > a number which, fortunately, was smaller than last year, when we'd > had 577 FTBFS to > investigate. MongoDB is not failing in your rebuild. However latest minor upgrade (v3.4.2) with gcc 7 is failing. I've figured out, that is optimization issue (with -O0 it is fine, with -01 it is failing) and it is ONLY ON ppc64le (other architectures are fine). I know which file is cause this issue, but I can't figure out with which optimization. I get what changes between O0 and O1 in output of 'gcc -O0/1 -Q --help=optimizers' and compiled with -O0 and flags of individual optimizations (which are added by O1), but failure does not appear. What else differs in -O1? How should I debug it? > > The Fedora packages I rebuilt were grabbed on Jan 12. > > It's all fairly good, and nothing particularly stands out. There is > the usual > batch of new warnings (-Wimplicit-fallthrough and -Wformat-truncation > causing > the biggest churn), some C++ FE changes (especially the "Fix type- > dependence > and the current instantiation" changes made the compiler to reject > invalid code > that had previously been accepted, plus invalid conversions with '\0' > are now > rejected), some libstdc++ changes (header dependency changes), as > well as some > mangling changes. > > We found several GCC bugs, most of which have already been > fixed. Furthermore, > Fortran ABI has changed in GCC 7. Anyway, there's nothing that > particularly > worries me (except perhaps the -fprintf-return-value stuff that might > still > cause some wrong codes). > > Shortlog appended for the people who want to get an overview of the > details. > > As usual, there will be a "porting to" document to ease the > transition to the > new GCC. We already have https://gcc.gnu.org/gcc-7/porting_to.html, > even though > this document is still somewhat in flux. > > I'd like to thank Jakub Jelinek and Jonathan Wakely, the guys I roped > in to help > me with all this undertaking. > > GCC bugs > > The following is a list of bugs we've found so far in the compiler > and the C++ > library during the mass rebuild: > > schroot-1.6.5-16.fc24.src.rpm > ICE in cxx_incomplete_type_diagnostic > https://gcc.gnu.org/PR78690 > not fixed yet > > python-plyvel-0.9-7.fc26.src.rpm > error: invalid rhs for gimple memory store > https://gcc.gnu.org/PR79232 > fixed in gcc-7.0.1-0.4.fc26 > > mathicgb-1.0-6.20160202.gitbb268df.fc26.src.rpm > ICE in tsubst_copy > https://gcc.gnu.org/PR79253 > fixed upstream and in gcc-7.0.1-0.5.fc26 > > cvc4-1.4-11.fc25.src.rpm > TLS model wrong for static data members > https://gcc.gnu.org/PR79288 > fixed in gcc-7.0.1-0.4.fc26 > > golang-1.7.4-1.fc26.src.rpm > DWARF info for typeof of C function with no args and no > prototype > is empty pointer > https://gcc.gnu.org/PR79289 > fixed upstream and in gcc-7.0.1-0.4.fc26 > > texlive-2016-30.20160520.fc26.src.rpm > tlog-2-1.fc25.src.rpm > wrong code at -O2 and -fprintf-return-value > https://gcc.gnu.org/PR79327 > fixed upstream and in gcc-7.0.1-0.6.fc26 > > perl-Prima-1.50-1.fc26.src.rpm > -fprintf-return-value doesn't handle flexible-like array > members properly > https://gcc.gnu.org/PR79352 > fixed upstream and in gcc-7.0.1-0.6.fc26 > > clucene09-0.9.21b-16.fc24.src.rpm > qt5-qttools-5.7.1-4.fc26.src.rpm > g++ rejects valid code with error: looser throw specifier > https://gcc.gnu.org/PR79393 class="Apple-tab-span" > style="white-space:pre"> > > Failures due to new warnings and -Werror > > efivar-30-4.fc26.src.rpm > a new -Walloc-size-larger-than warning > > bind-dyndb-ldap-11.0-1.fc26.src.rpm > efibootmgr-14-3.fc26.src.rpm > fwupdate-8-2.fc26.src.rpm > a new -Wduplicate-decl-specifier warning > > mstflint-4.4.0-1.12.gd1edd58.1.fc26.src.rpm > a new -Wformat-length warning > > blobwars-1.19-13.fc24.src.rpm > czmq-4.0.2-1.fc26.src.rpm > elfutils-0.168-1.fc26.src.rpm > fcoe-utils-1.0.30-5.git91c0c8c.fc24.src.rpm > glib2-2.51.0-2.fc26.src.rpm > glibc-2.24.90-26.fc26.src.rpm > ipv6calc-0.99.2-17.fc26.src.rpm > isomd5sum-1.1.0-4.fc26.src.rpm > ixpdimm_sw-01.00.00.2144-1.fc26.src.rpm > libhid-0.2.17-21.fc25.src.rpm > libpsm2-10.2.2-2.fc25.src.rpm > libyui-3.2.8-1.fc26.src.rpm > logrotate-3.11.0-2.fc26.src.rp
Re: Fedora mass rebuild 2017
On Tue, Feb 07, 2017 at 11:59:33PM +, Tom Hughes wrote:
> On 07/02/17 23:56, Stephen John Smoogen wrote:
> > On 7 February 2017 at 18:39, Sérgio Basto wrote:
> > > Hi,
> > > On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
> > > > some C++ FE changes (especially the "Fix type-dependence
> > > > and the current instantiation" changes made the compiler to reject
> > > > invalid code
> > > > that had previously been accepted, plus invalid conversions with '\0'
> > > > are now
> > > > rejected)
> > >
> > > Thanks for exhaustive explanation .
> > > I have this case, how we fix ?
> > > src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between
> > > pointer and integer [-fpermissive]
> > > if (pSlash != '\0') {
> > >
> >
> > Someone would need to see more code than that. How is pSlash declared?
> > What is the context of the code you have quoted?
>
> Well I'm guessing it's a pointer to char and that should probably be:
>
> if (*pSlash != '\0')
Yeah, or it can be also
if (pSlash != NULL)
or
if (pSlash)
etc.
It really depends on what the code is trying to do.
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On Tue, Feb 07, 2017 at 10:32:09PM +0100, Marek Polacek wrote: > ocp-0.1.22-0.10.git849cc42.fc26.src.rpm > These are not ready for a new gcc version (gcc -dumpversion says '7' > and not e.g. '6.3.1') and the packages fail to cope with that. Fixed, thanks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On Ter, 2017-02-07 at 19:19 -0500, Stephen John Smoogen wrote:
> On 7 February 2017 at 19:14, Sérgio Basto wrote:
> >
> > On Ter, 2017-02-07 at 18:56 -0500, Stephen John Smoogen wrote:
> > >
> > > On 7 February 2017 at 18:39, Sérgio Basto
> > > wrote:
> > > >
> > > >
> > > > Hi,
> > > > On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
> > > > >
> > > > >
> > > > > some C++ FE changes (especially the "Fix type-dependence
> > > > > and the current instantiation" changes made the compiler to
> > > > > reject
> > > > > invalid code
> > > > > that had previously been accepted, plus invalid conversions
> > > > > with
> > > > > '\0'
> > > > > are now
> > > > > rejected)
> > > >
> > > > Thanks for exhaustive explanation .
> > > > I have this case, how we fix ?
> > > > src/rtphint.cpp:342:35: error: ISO C++ forbids comparison
> > > > between
> > > > pointer and integer [-fpermissive]
> > > > if (pSlash != '\0') {
> > > >
> > >
> > > Someone would need to see more code than that. How is pSlash
> > > declared?
> > > What is the context of the code you have quoted?
> >
> > https://github.com/sergiomb2/libmp4v2/blob/master/src/rtphint.cpp#L
> > 342
> >
> > it is package libmp4v2 [1] but I just built it locally , let me
> > know if
> > you need more information .
> >
> > [1]
> > https://apps.fedoraproject.org/packages/libmp4v2
> >
>
> Thank you for the info. The fix Tom pointed out should be correct
> there. The pointer needs to be dereferenced so that the comparison is
> 'valid'
Fixed :) thanks
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 08/02/17 00:14, Sérgio Basto wrote:
On Ter, 2017-02-07 at 18:56 -0500, Stephen John Smoogen wrote:
On 7 February 2017 at 18:39, Sérgio Basto wrote:
Hi,
On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
some C++ FE changes (especially the "Fix type-dependence
and the current instantiation" changes made the compiler to
reject
invalid code
that had previously been accepted, plus invalid conversions with
'\0'
are now
rejected)
Thanks for exhaustive explanation .
I have this case, how we fix ?
src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between
pointer and integer [-fpermissive]
if (pSlash != '\0') {
Someone would need to see more code than that. How is pSlash
declared?
What is the context of the code you have quoted?
https://github.com/sergiomb2/libmp4v2/blob/master/src/rtphint.cpp#L342
So it's exactly as I said. That code is just wrong and should be:
if (*pSlash != '\0') {
As it stands the body of that if will always execute and when there are
no encoding parameters ppEncodingParams will be returned as a pointer to
an empty string rather than as a null pointer.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 7 February 2017 at 18:59, Tom Hughes wrote:
> On 07/02/17 23:56, Stephen John Smoogen wrote:
>>
>> On 7 February 2017 at 18:39, Sérgio Basto wrote:
>>>
>>> Hi,
>>> On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
some C++ FE changes (especially the "Fix type-dependence
and the current instantiation" changes made the compiler to reject
invalid code
that had previously been accepted, plus invalid conversions with '\0'
are now
rejected)
>>>
>>>
>>> Thanks for exhaustive explanation .
>>> I have this case, how we fix ?
>>> src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between
>>> pointer and integer [-fpermissive]
>>> if (pSlash != '\0') {
>>>
>>
>> Someone would need to see more code than that. How is pSlash declared?
>> What is the context of the code you have quoted?
>
>
> Well I'm guessing it's a pointer to char and that should probably be:
>
> if (*pSlash != '\0')
>
> That's nothing to do with gcc 7 though as gcc 6 should also have objected to
> that code.
Yeah.. I just wanted to make sure as sometimes people do strange
pointer comparisons and I didn't know how long the code had not
compiled.
Thanks for the tip.
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 7 February 2017 at 19:14, Sérgio Basto wrote:
> On Ter, 2017-02-07 at 18:56 -0500, Stephen John Smoogen wrote:
>> On 7 February 2017 at 18:39, Sérgio Basto wrote:
>> >
>> > Hi,
>> > On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
>> > >
>> > > some C++ FE changes (especially the "Fix type-dependence
>> > > and the current instantiation" changes made the compiler to
>> > > reject
>> > > invalid code
>> > > that had previously been accepted, plus invalid conversions with
>> > > '\0'
>> > > are now
>> > > rejected)
>> >
>> > Thanks for exhaustive explanation .
>> > I have this case, how we fix ?
>> > src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between
>> > pointer and integer [-fpermissive]
>> > if (pSlash != '\0') {
>> >
>>
>> Someone would need to see more code than that. How is pSlash
>> declared?
>> What is the context of the code you have quoted?
>
> https://github.com/sergiomb2/libmp4v2/blob/master/src/rtphint.cpp#L342
>
> it is package libmp4v2 [1] but I just built it locally , let me know if
> you need more information .
>
> [1]
> https://apps.fedoraproject.org/packages/libmp4v2
>
Thank you for the info. The fix Tom pointed out should be correct
there. The pointer needs to be dereferenced so that the comparison is
'valid'
--
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On Ter, 2017-02-07 at 18:56 -0500, Stephen John Smoogen wrote:
> On 7 February 2017 at 18:39, Sérgio Basto wrote:
> >
> > Hi,
> > On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
> > >
> > > some C++ FE changes (especially the "Fix type-dependence
> > > and the current instantiation" changes made the compiler to
> > > reject
> > > invalid code
> > > that had previously been accepted, plus invalid conversions with
> > > '\0'
> > > are now
> > > rejected)
> >
> > Thanks for exhaustive explanation .
> > I have this case, how we fix ?
> > src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between
> > pointer and integer [-fpermissive]
> > if (pSlash != '\0') {
> >
>
> Someone would need to see more code than that. How is pSlash
> declared?
> What is the context of the code you have quoted?
https://github.com/sergiomb2/libmp4v2/blob/master/src/rtphint.cpp#L342
it is package libmp4v2 [1] but I just built it locally , let me know if
you need more information .
[1]
https://apps.fedoraproject.org/packages/libmp4v2
Thanks,
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 07/02/17 23:56, Stephen John Smoogen wrote:
On 7 February 2017 at 18:39, Sérgio Basto wrote:
Hi,
On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
some C++ FE changes (especially the "Fix type-dependence
and the current instantiation" changes made the compiler to reject
invalid code
that had previously been accepted, plus invalid conversions with '\0'
are now
rejected)
Thanks for exhaustive explanation .
I have this case, how we fix ?
src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between
pointer and integer [-fpermissive]
if (pSlash != '\0') {
Someone would need to see more code than that. How is pSlash declared?
What is the context of the code you have quoted?
Well I'm guessing it's a pointer to char and that should probably be:
if (*pSlash != '\0')
That's nothing to do with gcc 7 though as gcc 6 should also have
objected to that code.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
On 7 February 2017 at 18:39, Sérgio Basto wrote:
> Hi,
> On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
>> some C++ FE changes (especially the "Fix type-dependence
>> and the current instantiation" changes made the compiler to reject
>> invalid code
>> that had previously been accepted, plus invalid conversions with '\0'
>> are now
>> rejected)
>
> Thanks for exhaustive explanation .
> I have this case, how we fix ?
> src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between
> pointer and integer [-fpermissive]
> if (pSlash != '\0') {
>
Someone would need to see more code than that. How is pSlash declared?
What is the context of the code you have quoted?
Thanks
> Best regards,
> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
--
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora mass rebuild 2017
Hi,
On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
> some C++ FE changes (especially the "Fix type-dependence
> and the current instantiation" changes made the compiler to reject
> invalid code
> that had previously been accepted, plus invalid conversions with '\0'
> are now
> rejected)
Thanks for exhaustive explanation .
I have this case, how we fix ?
src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between
pointer and integer [-fpermissive]
if (pSlash != '\0') {
Best regards,
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
