Does anyone build C-C TB under Debian using clang-10?
I suspect that I am a minority using Debian GNU/Linux.
Anyway, here is a recent local compilation issue under Debian GNU/Linux.
After about a couple of weeks of non-activity on my home PC due to day
work, I tried to update the source (after a few tweaks, I could get the
patches to apply cleanly. It seems extensive imap file copy patch
landed.), and updated the Debian packages (<- this may be a culprit),
then I could no longer compile C-C tree using clang-10.
It seems that, if I enable optimization, /usr/include/string.h contains
conflicting function definitions (for compile time optimization to use
built-in functins) which do not sit well with c++ according to
clang-10's error message.
There were some such string-function issues, and also a few other
conflicting error messages.
So I am suspecting something is wrong with the latest glibc header files
that interfere with the optimized c++ build.
Before I file a bug report to debian and glibc folks, I thought I would
check.
Typical problematic header declarations are as follows.
/* Search N bytes of S for C. */
#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
extern "C++"
{
extern void *memchr (void *__s, int __c, size_t __n)
__THROW __asm ("memchr") attribute_pure __nonnull ((1));
extern const void *memchr (const void *__s, int __c, size_t __n)
__THROW __asm ("memchr") attribute_pure __nonnull ((1));
if 0 /* ifdef OPTIMIZE */ <--------- *** I have to comment
out this.
__extern_always_inline void *
memchr (void *__s, int __c, size_t __n) __THROW
{
return __builtin_memchr (__s, __c, __n);
}
__extern_always_inline const void *
memchr (const void *__s, int __c, size_t __n) __THROW
{
return __builtin_memchr (__s, __c, __n);
}
endif
}
#else
extern void *memchr (const void *__s, int __c, size_t __n)
__THROW attribute_pure __nonnull ((1));
#endif
But even after I tweaked the system string.h header file along the line
of the changes above,
I still get the following, and
In file included from
/NEW-SSD/ASAN-OBJ-DIR/objdir-tb3/dist/system_wrappers/type_traits:3:
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:653:12:
error: class template partial specialization does not specialize any
template argument; to define the primary template, remove the template
argument list
struct is_const<_Tp const>
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:653:12:
error: redefinition of 'is_const'
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:649:12:
note: previous definition is here
struct is_const
^
In file included from Unified_cpp_accessible_aom0.cpp:2:
In file included from
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/accessible/aom/AccessibleNode.cpp:6:
This looks a bit deeper than I can easily analyze. Maybe C++ / C
semantics change?
(The code block that is involved in redefinition issue is surrounded by
#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
and this suggests some inter-language API issue.)
Anyway, if anyone sees similar errors, I would like to know what causes
the issues.
The same setup worked fine at the end of November.
I am using clang-10 to create ASAN build of C-C TB.
For non-ASAN ordinary build of C-C TB, I use gcc-10. That seems to
Chiaki
Would suspect it has something to do with bug 1679148 (or rather, the
changes that caused that).
-Magnus
On 2020-12-13 18:53, ISHIKAWA,chiaki wrote:
I suspect that I am a minority using Debian GNU/Linux.
Anyway, here is a recent local compilation issue under Debian GNU/Linux.
After about a couple of weeks of non-activity on my home PC due to day
work, I tried to update the source (after a few tweaks, I could get
the patches to apply cleanly. It seems extensive imap file copy patch
landed.), and updated the Debian packages (<- this may be a culprit),
then I could no longer compile C-C tree using clang-10.
It seems that, if I enable optimization, /usr/include/string.h contains
conflicting function definitions (for compile time optimization to use
built-in functins) which do not sit well with c++ according to
clang-10's error message.
There were some such string-function issues, and also a few other
conflicting error messages.
So I am suspecting something is wrong with the latest glibc header
files that interfere with the optimized c++ build.
Before I file a bug report to debian and glibc folks, I thought I
would check.
Typical problematic header declarations are as follows.
/* Search N bytes of S for C. */
#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
extern "C++"
{
extern void *memchr (void *__s, int __c, size_t __n)
__THROW __asm ("memchr") attribute_pure __nonnull ((1));
extern const void *memchr (const void *__s, int __c, size_t __n)
__THROW __asm ("memchr") attribute_pure __nonnull ((1));
if 0 /* ifdef OPTIMIZE */ <--------- *** I have to
comment out this.
__extern_always_inline void *
memchr (void *__s, int __c, size_t __n) __THROW
{
return __builtin_memchr (__s, __c, __n);
}
__extern_always_inline const void *
memchr (const void *__s, int __c, size_t __n) __THROW
{
return __builtin_memchr (__s, __c, __n);
}
endif
}
#else
extern void *memchr (const void *__s, int __c, size_t __n)
__THROW attribute_pure __nonnull ((1));
#endif
But even after I tweaked the system string.h header file along the
line of the changes above,
I still get the following, and
In file included from
/NEW-SSD/ASAN-OBJ-DIR/objdir-tb3/dist/system_wrappers/type_traits:3:
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:653:12:
error: class template partial specialization does not specialize any
template argument; to define the primary template, remove the template
argument list
struct is_const<_Tp const>
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:653:12:
error: redefinition of 'is_const'
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:649:12:
note: previous definition is here
struct is_const
^
In file included from Unified_cpp_accessible_aom0.cpp:2:
In file included from
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/accessible/aom/AccessibleNode.cpp:6:
This looks a bit deeper than I can easily analyze. Maybe C++ / C
semantics change?
(The code block that is involved in redefinition issue is surrounded by
#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
and this suggests some inter-language API issue.)
Anyway, if anyone sees similar errors, I would like to know what
causes the issues.
The same setup worked fine at the end of November.
I am using clang-10 to create ASAN build of C-C TB.
For non-ASAN ordinary build of C-C TB, I use gcc-10. That seems to
Chiaki
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 2020/12/14 4:18, Magnus Melin wrote:
Would suspect it has something to do with bug 1679148 (or rather, the
changes that caused that).
-Magnus
Thank you. That seems to explain part of the issue.
I will investigate more why I hit it. I think ASAN build defines many
macros and thus we may hit unexpected errors.
After trying to see if gcc-10 can finish the build, I have recalled why
I have switched to clang-10 for ASAN build. (Earlier this year, gcc
could not compile it. For a while it seems it could. But now g++-10, the
latest binary encounters internal compiler error and can't be used. I
have filed a bug report, but it seems it may not be easy to fix it...
So maybe I should downgrade to g++-9 until the ICE is fixed.)
Chiaki
On 2020-12-13 18:53, ISHIKAWA,chiaki wrote:
I suspect that I am a minority using Debian GNU/Linux.
Anyway, here is a recent local compilation issue under Debian GNU/Linux.
After about a couple of weeks of non-activity on my home PC due to
day work, I tried to update the source (after a few tweaks, I could
get the patches to apply cleanly. It seems extensive imap file copy
patch landed.), and updated the Debian packages (<- this may be a
culprit),
then I could no longer compile C-C tree using clang-10.
It seems that, if I enable optimization, /usr/include/string.h contains
conflicting function definitions (for compile time optimization to
use built-in functins) which do not sit well with c++ according to
clang-10's error message.
There were some such string-function issues, and also a few other
conflicting error messages.
So I am suspecting something is wrong with the latest glibc header
files that interfere with the optimized c++ build.
Before I file a bug report to debian and glibc folks, I thought I
would check.
Typical problematic header declarations are as follows.
/* Search N bytes of S for C. */
#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
extern "C++"
{
extern void *memchr (void *__s, int __c, size_t __n)
__THROW __asm ("memchr") attribute_pure __nonnull ((1));
extern const void *memchr (const void *__s, int __c, size_t __n)
__THROW __asm ("memchr") attribute_pure __nonnull ((1));
if 0 /* ifdef OPTIMIZE */ <--------- *** I have to
comment out this.
__extern_always_inline void *
memchr (void *__s, int __c, size_t __n) __THROW
{
return __builtin_memchr (__s, __c, __n);
}
__extern_always_inline const void *
memchr (const void *__s, int __c, size_t __n) __THROW
{
return __builtin_memchr (__s, __c, __n);
}
endif
}
#else
extern void *memchr (const void *__s, int __c, size_t __n)
__THROW attribute_pure __nonnull ((1));
#endif
But even after I tweaked the system string.h header file along the
line of the changes above,
I still get the following, and
In file included from
/NEW-SSD/ASAN-OBJ-DIR/objdir-tb3/dist/system_wrappers/type_traits:3:
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:653:12:
error: class template partial specialization does not specialize any
template argument; to define the primary template, remove the
template argument list
struct is_const<_Tp const>
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:653:12:
error: redefinition of 'is_const'
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:649:12:
note: previous definition is here
struct is_const
^
In file included from Unified_cpp_accessible_aom0.cpp:2:
In file included from
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/accessible/aom/AccessibleNode.cpp:6:
This looks a bit deeper than I can easily analyze. Maybe C++ / C
semantics change?
(The code block that is involved in redefinition issue is surrounded by
#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
and this suggests some inter-language API issue.)
Anyway, if anyone sees similar errors, I would like to know what
causes the issues.
The same setup worked fine at the end of November.
I am using clang-10 to create ASAN build of C-C TB.
For non-ASAN ordinary build of C-C TB, I use gcc-10. That seems to
Chiaki
On 14/12/20 5:53 am, ISHIKAWA,chiaki wrote:
I suspect that I am a minority using Debian GNU/Linux.
I'm running Debian (test + rare sprinkles from unstable).
But I guess I'm running the mach bootstrap clang:
$ clang --version
bash: clang: command not found
$ ~/.mozbuild/clang/bin/clang --version
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/ben/.mozbuild/clang/bin
So that's probably not much use to you.
I'm running a debug build, but with optimisation turned on (waaaay too
slow without it!). Compiled fine as of yesterday.
Let me know if there's anything you want me to try out.
Ben.
Dňa 14. 12. 2020 o 7:43 Ben Campbell napísal(a):
So that's probably not much use to you.
I'm running a debug build, but with optimisation turned on (waaaay too
slow without it!). Compiled fine as of yesterday.
Hi, yes debug build got very slow in the recent months. How do you "turn
on optimisations"? There is an --disable-optimize option to turn them
off. Is there something more?
On 2020/12/14 15:43, Ben Campbell wrote:
On 14/12/20 5:53 am, ISHIKAWA,chiaki wrote:
I suspect that I am a minority using Debian GNU/Linux.
I'm running Debian (test + rare sprinkles from unstable).
But I guess I'm running the mach bootstrap clang:
$ clang --version
bash: clang: command not found
$ ~/.mozbuild/clang/bin/clang --version
clang version 11.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/ben/.mozbuild/clang/bin
So that's probably not much use to you.
I'm running a debug build, but with optimisation turned on (waaaay too
slow without it!). Compiled fine as of yesterday.
Let me know if there's anything you want me to try out.
Ben.
Thank you for your data point.
Then, I suppose ASAN build does something funny that confuses the header
processing.
(I am using clang-10 for ASAN build.)
Well, I suppose I should bite the bullet for now and switch to clang-10
then for ordinary local build since you seem to be able to build TB
under Debian GNU/Linux.
I have stuck to gcc and will do so if build is successful because using
different compilers often reveals the problems in the code, i.e.,
dubious construct that abuses the ambiguous description in the language
spec., or the particular compiler's incorrect reading of the language spec.
Using different compilers often reveal these issues early on. Both in
the TB source code and compilers themselves. I mean, I don't use clang
very often unless the build problem arises with gcc. So the whole TB
community uses clang while I try to use gcc locally as often as
possible. So I can catch the problems mentioned above locally.
Well, I am from embedded systems background, and there, gcc has been
almost the default compiler for some CPUs.
That is why I want to keep GCC in good shape as much as possible.
Chiaki
On 2020/12/14 16:16, ace wrote:
Dňa 14. 12. 2020 o 7:43 Ben Campbell napísal(a):
So that's probably not much use to you.
I'm running a debug build, but with optimisation turned on (waaaay too
slow without it!). Compiled fine as of yesterday.
Hi, yes debug build got very slow in the recent months. How do you "turn
on optimisations"? There is an --disable-optimize option to turn them
off. Is there something more?
I have --enable-optimize in my mozconfig as follows:
Nov 2020 add -fanalyzer
ac_add_options --enable-optimize="-g -Og -fvar-tracking -gdwarf-4
-fvar-tracking-assignments -freorder-blocks -fanalyzer"
Most of the options are for valgrind usage.
Don't try -fanalyzer. Remove it.
It is a memory hog to the point that, I think, triggers a bug in either linux or VirtualBox
when the swap is exhausted.: Some type of soft deadlock is observed.
I say "soft" because sometimes I can get out of it by sending a signal to from virtualbox GUI.
But that signal is actually supposed to shutdown the system. So I am not sure what goes on.
Chiaki
Or it could be related to
https://groups.google.com/g/mozilla.dev.platform/c/lQ1IhWVJFKs
Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1676346
https://bugzilla.mozilla.org/show_bug.cgi?id=1676346
On 2020/12/14 4:18, Magnus Melin wrote:
Would suspect it has something to do with bug 1679148 (or rather, the
changes that caused that).
-Magnus
On 2020-12-13 18:53, ISHIKAWA,chiaki wrote:
I suspect that I am a minority using Debian GNU/Linux.
Anyway, here is a recent local compilation issue under Debian GNU/Linux.
After about a couple of weeks of non-activity on my home PC due to
day work, I tried to update the source (after a few tweaks, I could
get the patches to apply cleanly. It seems extensive imap file copy
patch landed.), and updated the Debian packages (<- this may be a
culprit),
then I could no longer compile C-C tree using clang-10.
It seems that, if I enable optimization, /usr/include/string.h contains
conflicting function definitions (for compile time optimization to
use built-in functins) which do not sit well with c++ according to
clang-10's error message.
There were some such string-function issues, and also a few other
conflicting error messages.
So I am suspecting something is wrong with the latest glibc header
files that interfere with the optimized c++ build.
Before I file a bug report to debian and glibc folks, I thought I
would check.
Typical problematic header declarations are as follows.
/* Search N bytes of S for C. */
#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
extern "C++"
{
extern void *memchr (void *__s, int __c, size_t __n)
__THROW __asm ("memchr") attribute_pure __nonnull ((1));
extern const void *memchr (const void *__s, int __c, size_t __n)
__THROW __asm ("memchr") attribute_pure __nonnull ((1));
if 0 /* ifdef OPTIMIZE */ <--------- *** I have to
comment out this.
__extern_always_inline void *
memchr (void *__s, int __c, size_t __n) __THROW
{
return __builtin_memchr (__s, __c, __n);
}
__extern_always_inline const void *
memchr (const void *__s, int __c, size_t __n) __THROW
{
return __builtin_memchr (__s, __c, __n);
}
endif
}
#else
extern void *memchr (const void *__s, int __c, size_t __n)
__THROW attribute_pure __nonnull ((1));
#endif
But even after I tweaked the system string.h header file along the
line of the changes above,
I still get the following, and
In file included from
/NEW-SSD/ASAN-OBJ-DIR/objdir-tb3/dist/system_wrappers/type_traits:3:
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:653:12:
error: class template partial specialization does not specialize any
template argument; to define the primary template, remove the
template argument list
struct is_const<_Tp const>
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:653:12:
error: redefinition of 'is_const'
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:649:12:
note: previous definition is here
struct is_const
^
In file included from Unified_cpp_accessible_aom0.cpp:2:
In file included from
/NEW-SSD/NREF-COMM-CENTRAL/mozilla/accessible/aom/AccessibleNode.cpp:6:
This looks a bit deeper than I can easily analyze. Maybe C++ / C
semantics change?
(The code block that is involved in redefinition issue is surrounded by
#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
and this suggests some inter-language API issue.)
Anyway, if anyone sees similar errors, I would like to know what
causes the issues.
The same setup worked fine at the end of November.
I am using clang-10 to create ASAN build of C-C TB.
For non-ASAN ordinary build of C-C TB, I use gcc-10. That seems to
Chiaki
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net