Closed Bug 1677848 Opened 4 years ago Closed 3 years ago

Fail to buid release - type_traits - STL code can only be used with infallible ::operator new()"

Categories

(SeaMonkey :: Build Config, defect)

SeaMonkey 2.53 Branch
x86_64
FreeBSD
defect

Tracking

(Not tracked)

RESOLVED FIXED

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

OS: Unspecified → FreeBSD
Hardware: Unspecified → x86_64

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.

Also happens when trying to compile 2.53.5.1 on FreeBSD 12.2.

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.

Also 2.53.6 is affected

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

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.

Did you try together with the patch for bug 1594027 ?

Status: UNCONFIRMED → NEW
Ever confirmed: true

Bug 1594027 is in SeaMonkey 2.53.7 final. Bug 1442403 will be in 2.53.8 only.

Bug fixed in 2.53.8 - buit fine on 12.2

Then lets close it before you find new problems in 2.53.9 soon :) (I hope not)

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.