Open catap opened 4 months ago
rmottola
commented
4 months ago Same error here on OpenBSD 7.5. Works on linux with gcc14 and on FreeBSD with clang12.
Please try using system spellchecker. Install hunspell and add to mozconfig
ac_add_options --enable-system-hunspell
don't know what is different here for OpenBSD, maybe clang version, didn't play around.
rmottola
commented
4 months ago On x86 32bit 7.5 clang16 with system hunspell I fail now with:
5:18.78 In file included from /home/multix/code/Arctic-Fox/obj-i386-unknown-openbsd7.5/dist/stl_wrappers/vector:52:
5:18.79 In file included from /home/multix/code/Arctic-Fox/obj-i386-unknown-openbsd7.5/dist/system_wrappers/vector:4:
5:18.79 /usr/include/c++/v1/vector:860:7: error: call to '__throw_out_of_range' is ambiguous
5:18.79 std::__throw_out_of_range("vector");
5:18.79 ^~~~~~~~~~~~~~~~~~~~~~~~~
5:18.79 /home/multix/code/Arctic-Fox/obj-i386-unknown-openbsd7.5/dist/include/mozilla/throw_gcc.h:108:1: note: candidate function
5:18.79 __throw_out_of_range(const char* msg)
5:18.79 ^
5:18.79 /usr/include/c++/v1/stdexcept:265:6: note: candidate function
5:18.79 void __throw_out_of_range(const char*__msg)
5:18.79 ^
catap
commented
3 months ago Sorry for long reply.
I had installed hunspell already and it was picked by configure.
Arctic-Fox $ pkg_info | grep hunspell
hunspell-1.7.2 spelling, stemming, morphological analysis and generation
Arctic-Fox $ Anyway, if I add ac_add_options --enable-system-hunspell nothing is changed.
rmottola
commented
3 months ago @catap interestingly, I tried on 7.0 with system clang and it still compiles and works there, so it must be some kind if incompatibility of 7.5
catap
commented
3 months ago Well, between 7.5 and 7.0... more than 2 years of development. Trace the issue is quite complicated.
rmottola
commented
3 months ago I know, but still a useful check that the AF code didn't break where it did work already.
catap
commented
3 months ago Here a way to run different BSD via github action https://github.com/catap/shell , it probably can be used to build a CI to catch if something is broken.
Anyway, I'm digging into hunspell right now, if I discover something, I let you know.
catap
commented
3 months ago Well, https://github.com/rmottola/Arctic-Fox/pull/211 fixes my issue and I was able to build it.
catap
commented
3 months ago @rmottola my bet that you can build it on 7.4 without any issue. And the root cause of this issue is https://github.com/OpenBSD/src/commit/dc37c87a60a1e3d67c2ac5d5c5b9fc1e4af89632 and a chunk:
@@ -2868,7 +2824,7 @@ __double_or_nothing(unique_ptr<_Tp, void(*)(void*)>& __b, _Tp*& __n, _Tp*& __e)
if (__new_cap == 0)
__new_cap = sizeof(_Tp);
size_t __n_off = static_cast<size_t>(__n - __b.get());
- _Tp* __t = (_Tp*)realloc(__owns ? __b.get() : 0, __new_cap);
+ _Tp* __t = (_Tp*)std::realloc(__owns ? __b.get() : 0, __new_cap);
if (__t == 0)
__throw_bad_alloc();
if (__owns)Before that realloc was replaced into HunspellAllocator::CountingRealloc and it works. After that it is replaced into std::HunspellAllocator::CountingRealloc and we have this wired issue.
catap
commented
3 months ago @rmottola here the same issue on FreeBSD https://forums.mozillazine.org/viewtopic.php?t=3117607 with the same Clang/LLVM which is in base at OpenBSD.
catap
commented
3 months ago Well, this issue is triggered by this changes https://github.com/llvm/llvm-project/commit/841399a2188aaf244e83e3df7be66885ec905ede which is included into LLVM-16
I not sure how can it be fixed properly
catap
commented
3 months ago Well, seems that such issue had happened not only for Firefox https://community.graphisoft.com/t5/Archicad-C-API/Compile-error-on-Mac/td-p/575888/page/2, https://github.com/facebook/rocksdb/issues/12708, https://stackoverflow.com/questions/77253911/cpputest-realloc-conflict-with-iostream-when-compiling-with-clang, https://review.couchbase.org/c/forestdb/+/208898 and so on
rmottola
commented
3 months ago On x86 32bit 7.5 clang16 with system hunspell I fail now with:
5:18.78 In file included from /home/multix/code/Arctic-Fox/obj-i386-unknown-openbsd7.5/dist/stl_wrappers/vector:52: 5:18.79 In file included from /home/multix/code/Arctic-Fox/obj-i386-unknown-openbsd7.5/dist/system_wrappers/vector:4: 5:18.79 /usr/include/c++/v1/vector:860:7: error: call to '__throw_out_of_range' is ambiguous 5:18.79 std::__throw_out_of_range("vector"); 5:18.79 ^~~~~~~~~~~~~~~~~~~~~~~~~ 5:18.79 /home/multix/code/Arctic-Fox/obj-i386-unknown-openbsd7.5/dist/include/mozilla/throw_gcc.h:108:1: note: candidate function 5:18.79 __throw_out_of_range(const char* msg) 5:18.79 ^ 5:18.79 /usr/include/c++/v1/stdexcept:265:6: note: candidate function 5:18.79 void __throw_out_of_range(const char*__msg) 5:18.79 ^
this should be fixed, I fixed it for FreeBSD.
catap
commented
3 months ago Do you have any idea how to fix it?
rmottola
commented
3 months ago Do you have any idea how to fix it?
do you mean the realloc vs std::realloc issue? not yet. I am hit by it on FreeBSD after I updated. Things I read around are contradictory right now. I confirm it is a clang/llvm issue. I was not able to build a running browser on FreeBSD or OpenBSD with gcc though. I can build using GCC on FreeBSD but it fails to start. I will continue testing the next coming days.
The issue seems to be more complicated in Firefox and derivates due to system wrappers and #defines
rmottola
commented
3 months ago catap
commented
3 months ago Yeah, this link quite wired and it ends (or at leas I understand it that way) that author switched to use old binary that isn't solution here.
rmottola
commented
3 months ago Yes, using an older version is not an option. But seeing the error on seamonkey shows it is not an ArcticFox specific issue.
rmottola
commented
3 months ago On FreeBSD I tried removing hunspell glue files from unified sources (as was a hint in the palemoon forum) but it did not help
catap
commented
2 months ago Can you try https://github.com/rmottola/Arctic-Fox/pull/211 on FreeBSD? I think it will fix this issue for now, but I have no idea how to fix it in the generic way.
rmottola
commented
2 months ago @catap I will... I just tryed #211 on FreeBSD with a couple of patches... it builds. But it crashes of startup!! darn. I will anyway try OpenBSD too, just do see.
rmottola
commented
2 months ago @catap I also tried on OpenBSD today. It builds, but then crashes on startup too.
catap
commented
2 months ago So, it's doomed :)
BTW, Pale Moon had quite a story with attempt to bring it into OpenBSD. You may read the last discussion here: https://forum.palemoon.org/viewtopic.php?f=5&t=30732&p=247364 and the whole sotre https://web.archive.org/web/20240723175908/https://github.com/jasperla/openbsd-wip/issues/86 which was saved on only in archive :)
rmottola
commented
2 months ago Doomed... well, until a better solution is found by somebody... Maybe somebody builds PaleMoon on FreeBSD or OpenBSD with clang or anyway same llvm version. I don't know how things fare with SeaMonkey.. or perhaps they maintain older ESR versions of Firefox like NetBSD does.
We don't have an issue in a dependent library, so the cited issue PaleMoon doesn't apply.
Also, ArcticFox right now doesn't impose any limitations on branding. No issues were found yet. I understand PaleMoon's reasons though.
rmottola
commented
4 days ago @catap I imported some fixes on the build system, including wrappers to the standard headers. This has the nice effect that with GCC everything compiles and works, no more arc4random issues! I am still testing... but browser is starting and doing basic stuff (standard caveat about optimisations for gcc > 6.x applies). Clang remains broken.
catap
commented
4 days ago @rmottola I've tried dev branch (local root 413f36554d4e7ebf86c9a585099be9122d8208da) and it failed as before:
71:27.03 In file included from /home/catap/src/Arctic-Fox/obj-amd64-unknown-openbsd7.6/dist/system_wrappers/locale:4:
71:27.03 /usr/include/c++/v1/locale:2827:22: error: no member named 'HunspellAllocator' in namespace 'std'; did you mean simply 'HunspellAllocator'?
71:27.03 _Tp* __t = (_Tp*)std::realloc(__owns ? __b.get() : 0, __new_cap);
71:27.03 ^@catap which gcc did you use? it compiles for me. Do you need mozconfigure extract? it is egcc once installed
catap
commented
4 days ago @rmottola I've used clang as usuall. I'll try gcc later this week.
Hey,
I've tried to build it on OpenBSD 7.5. I had used
mozcfg-i386OpenBSDas.mozconfig. The build is failed as: