Can't build on OpenBSD 7.5 amd64 #208
Comments
|
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
don't know what is different here for OpenBSD, maybe clang version, didn't play around. |
|
On x86 32bit 7.5 clang16 with system hunspell I fail now with: |
|
Sorry for long reply. I had installed Anyway, if I add |
|
@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 |
|
Well, between 7.5 and 7.0... more than 2 years of development. Trace the issue is quite complicated. |
|
I know, but still a useful check that the AF code didn't break where it did work already. |
|
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. |
|
Well, #211 fixes my issue and I was able to build it. |
|
@rmottola my bet that you can build it on 7.4 without any issue. And the root cause of this issue is openbsd/src@dc37c87 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 |
|
@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. |
|
Well, this issue is triggered by this changes llvm/llvm-project@841399a which is included into LLVM-16 I not sure how can it be fixed properly |
|
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, facebook/rocksdb#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 |
this should be fixed, I fixed it for FreeBSD. |
|
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. The issue seems to be more complicated in Firefox and derivates due to system wrappers and #defines |
|
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. |
|
Yes, using an older version is not an option. But seeing the error on seamonkey shows it is not an ArcticFox specific issue. |
|
On FreeBSD I tried removing hunspell glue files from unified sources (as was a hint in the palemoon forum) but it did not help |
|
Can you try #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. |
|
@catap I also tried on OpenBSD today. It builds, but then crashes on startup too. |
|
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 :) |
|
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. |
|
@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. |
|
@rmottola I've tried |
|
@catap which gcc did you use? it compiles for me. Do you need mozconfigure extract? it is egcc once installed |
|
@rmottola I've used clang as usuall. I'll try gcc later this week. |
|
@catap I specified that clang is still broken... GCC worked. I also built with gcc on 32bit Intel and it compiles. builds and run! So at least, there is a solution now, the ehader fixes had an impact. Recentclang remains broken |
|
@rmottola how can I switch building to use gcc? I'v added into top of but it still uses |
|
strange, are you sure you don't override the variables? I have for my Core i5: Of course, on 32bit different CPU, but the override works that way... maybe you override it with different compiler tests? happened to me... check the configure output: then for gcc > 6.x you need:
|
|
I had noticed it because build fails as usual on At begining it indeed used |
|
@catap this is strange...where does it fail? Are you using the "dev" branch? |
|
Long story short: Now it builds by gcc on OpenBSD but fails on start. |
|
remove of obj-dir should be enough? or "mach clobber". Things shouldn't be written outside of it. I just tried today again on 64bit with current dev and indeed, everything compiles, but fails to start
apparently a file is missing, but which one exactly? and why only OpenBSD? linux and FreeBSD continue to work! Mac too! |
|
The missing file was not fatal, but I fixed it. 7.5 64bit: crash on startup So.. it worked and now is broken for me. Bisecting since last fortnight? volunteering, @catap :) otherwise I might try next week myself. |
|
Broken commit: commit e8f2338 (HEAD) Working commit: commit 8f3876e (HEAD) |
|
@catap I narrowed it down and cross-checked to this commit: commit e8f2338 (HEAD) But I see nothing wrong that could affect OpenBSD but not FreeBSD/Linux/Mac... |
|
Not yet tested, just read commit. I see here |
|
@catap I don't think so, that just says validity of the probe, also is it not OS specific. I tracked it down to these two function calls: testing and having no execution (telemetry) proves that both make things fail. Especially cmdLine.findFlag makes it crash immediately! (I do not provide an url command, so it should find nothing). |
|
OpenBSD uses ksh by default which has it's differences with compare with bash. Can it be an issue? |
|
@catap hard to say, but I don't think here. Parameter reading should not be shell dependant, however I wonder how cmdLine.findFlag flags and how ShellService.isDefaultBrowser is checked. Most probably this bug was fixed later... esr52 does work on OpenBSD, doesn't it? On corrent OpenBSD that is. |
|
I have no idea. |
|
I tracked down that certain Linux systems, including my Raspberry have the same issue: Why instead it does work on Gentoo I don't know. Maybe it is really a default shell issue Devuan uses dash |
Hey,
I've tried to build it on OpenBSD 7.5. I had used
mozcfg-i386OpenBSDas.mozconfig. The build is failed as:The text was updated successfully, but these errors were encountered: