Fail to buid release - type_traits - STL code can only be used with infallible ::operator new()"
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
People
(Reporter: rm, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 SeaMonkey/2.53.4
Steps to reproduce:
Build on FreeBSD 12.2 x86-64 of 2.53.5 release.
Actual results:
Build fails:
libfreetype.a.desc
In file included from /usr/home/multix/code/seamonkey-2.53.5/obj-x86_64-unknown-freebsd12.2/xpcom/typelib/xpt/Unified_cpp_xpcom_typelib_xpt0.cpp:2:
In file included from /usr/home/multix/code/seamonkey-2.53.5/mozilla/xpcom/typelib/xpt/xpt_arena.cpp:13:
In file included from /usr/home/multix/code/seamonkey-2.53.5/mozilla/xpcom/typelib/xpt/xpt_arena.h:13:
In file included from /usr/home/multix/code/seamonkey-2.53.5/obj-x86_64-unknown-freebsd12.2/dist/system_wrappers/stdlib.h:3:
In file included from /usr/include/c++/v1/stdlib.h:100:
In file included from /usr/home/multix/code/seamonkey-2.53.5/obj-x86_64-unknown-freebsd12.2/dist/system_wrappers/math.h:3:
In file included from /usr/include/c++/v1/math.h:311:
/usr/home/multix/code/seamonkey-2.53.5/obj-x86_64-unknown-freebsd12.2/dist/stl_wrappers/type_traits:54:6: error: "STL code can only be used with infallible ::operator
new()"
error "STL code can only be used with infallible ::operator new()"
^
Compiling gkrust v0.1.0 (/usr/home/multix/code/seamonkey-2.53.5/mozilla/toolkit/library/rust)
I found two related bugs
- https://bugzilla.mozilla.org/show_bug.cgi?id=897674 which seems fixed a long ago
- https://bugzilla.mozilla.org/show_bug.cgi?id=1298566 which is now makerd as non-blocking, I'm using a release tarball, no special builds - perhaps it is related and/or seamonkey has a different configuration. Or perhaps it is/was another file!
The same error occurs when trying to compile 2.53.4 or 2.53.3 on FreeBSD 12.2 and also trying to compile 2.53.4 on FreeBSD 11.4. I did compile 2.53.3 on FreeBSD without any arror, though. Other combinations untested.
2.53.4 built on FreeBSD 12.1 (and continues to runs a bit unstable in compatibility) but if trying to re-build it in 12.2 it fails with the same error. This proves it is not a seamonkey code change, but an update in FreeBSD compiler and libraries.
Since the error occurs here, I wonder if there could be a workaround:
if !defined(XPCOM_GLUE) && !defined(NS_NO_XPCOM) && !defined(MOZ_NO_MOZALLOC)
include "mozilla/mozalloc.h"
else
error "STL code can only be used with infallible ::operator new()"
endif
#endif
What do I have to do to end up with XPCOM_GLUE, NS_NO_XPCOM or MOZ_NO_MOZALLOC and what would be the consequences of that?
I did some research. Mozilla has this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1594027
I tried applying it, but it does not help, perhaps something else is missing?
Then further, PaleMoon has some work on FreeBSD support which is worth investigating:
https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1736
Comment 8•3 years ago
|
||
Check if Bug 1442403 helps. It is basically a one liner. Just added it to 2.53.8b1 pre.
Frank-Rainer, I think it helps, because it compiles further. Still, I cannot confirm success, because build fails with:
44:44.03 In file included from /usr/home/multix/code/seamonkey-2.53.6/obj-x86_64-unknown-freebsd12.2/dist/system_wrappers/exception:3:
44:44.03 /usr/include/c++/v1/exception:182:5: error: no member named 'abort' in namespace 'std::__1'; did you mean simply 'abort'?
44:44.03 _VSTD::abort();
44:44.03 ^~~~~~~
44:44.03 /usr/include/c++/v1/__config:782:15: note: expanded from macro '_VSTD'
44:44.03 #define _VSTD std::_LIBCPP_ABI_NAMESPACE
44:44.03 ^
44:44.04 /usr/include/stdlib.h:86:17: note: 'abort' declared here
44:44.04 _Noreturn void abort(void);
44:44.04 ^
44:44.34 1 error generated.
Comment 10•3 years ago
|
||
Did you try together with the patch for bug 1594027 ?
Updated•3 years ago
|
Comment 11•3 years ago
|
||
Bug 1594027 is in SeaMonkey 2.53.7 final. Bug 1442403 will be in 2.53.8 only.
Reporter | ||
Comment 12•3 years ago
|
||
Bug fixed in 2.53.8 - buit fine on 12.2
Comment 13•3 years ago
|
||
Then lets close it before you find new problems in 2.53.9 soon :) (I hope not)
Description
•