Bug 201623
| Summary: | /usr/ports/graphics/dri fails on powerpc | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | herminio.hernandezjr | ||||||
| Component: | Individual Port(s) | Assignee: | freebsd-x11 (Nobody) <x11> | ||||||
| Status: | Closed Feedback Timeout | ||||||||
| Severity: | Affects Only Me | CC: | arved, danfe, jwb, marklmi26-fbsd, ppc, zeising | ||||||
| Priority: | --- | ||||||||
| Version: | Latest | ||||||||
| Hardware: | powerpc | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
Created attachment 158857 [details]
log file
This is a segfault of the compiler. Have you tried another compiler by setting CC/CXX? This issue looks familiar. Does the linker hang for a long time before crashing? In that case, the linker leaked memory until malloc failed and then crashed. I worked around this by following a suggestion to force it to use /usr/local/bin/ld. That would be less costly than adding a compiler dependency to the port. Warning: clang 3.8.0 (and likely before) has various problems for powerpc (and sometimes powerpc64) code generation: I modify signal delivery in my powerpc FreeBSD builds to have a so-called "red-zone" to avoid the following powerpc ABI-violation issue. (powerpc64 already has "red-zone" use because that is part of the powerpc64 ABI used by FreeBSD.) https://llvm.org/bugs/show_bug.cgi?id=26519 Some parts of the following item apply to more general code generation contexts than just exception-handling, although it started with finding exception-handling examples. https://llvm.org/bugs/show_bug.cgi?id=26856 The below 2 are for exception-handling code generation issues (counting .eh_frame information as code). https://llvm.org/bugs/show_bug.cgi?id=26761 https://llvm.org/bugs/show_bug.cgi?id=26844 The 1 item below was fixed in 3.8.0 rc3 but not in rc2 or earlier versions. https://llvm.org/bugs/show_bug.cgi?id=26605 (All these submittals to llvm.org came from attempting to use clang 3.8.0 for TARGET_ARCH=powerpc buildworld on an old PowerMac. As I remember all of the above seemed to be long-standing issues, not recent regressions. There are some matching FreeBSD submittals but until things change at llvm.org. . .) Hi! Is this still an issue with an updated version of the FreBSD xorg ports? (In reply to Mark Millard from comment #4) A clang status update: clang 4 and clang 5 are better behaved for TARGET_ARCH=powerpc . There is a problem if clang built the system library code involved in handling thrown C++ exceptions (process crash). But there was a fix to the system ld to fix clang-based C++ exception operation when the system libraries are built by gcc (such as the system gcc 4.2.1 compiler): Roman Divacky rdivacky at freebsd.org wrote on Sat Oct 7 10:03:10 UTC 2017 : > In a followup to https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html > > I attempted to fix gnu ld in base to fix the wrongly set bit. > > The following patch > http://www.vlakno.cz/~rdivacky/ppc64.exceptions.fix.patch > > switches a few computations to happen in 64bits instead of 32bit and fixes the > wrong personality/LDSA info in binaries. > > As a result clang compiled/assembled c++ binaries with EH start to work for me. > > Can someone verify this works for everyone? I can see the same cast in upstream > binutils but in a couple more places, so this is probably not the final answer > but is good enough for me. For more see: https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-October/003349.html Hi! This feels like an issue in the FreeBSD toolchain for ppc rather than an issue with the port directly? I have no ppc or ppc64 system to test with, so I need help in fixing this. (In reply to Niclas Zeising from comment #7) Some ports allow picking compilers/toolchains that are used in building the port. Others only work with a specific family. Yet others with only specific vintages/versions. What are the constraints on the graphics/mesa-dri compiler/toolchain usage? Can something like lang/gcc6 be used by graphics/mesa-dri ? (Might also require devel/binutils instead of the system toolchain.) If yes, then switching the port to use such a lang/gcc* (and devel/binutils ) might avoid any issues with the previously default compiler, whatever it was. (Presumes someone then uses a powerpc host to test the alternate compiler and toolchain.) If no, then can graphics/mesa-dri be modified to allow alternative compilers/toolchains from ports to be tried by those with an appropriate context for targeting powerpc? [My normal powerpc64 and powerpc context is not a great test case because buildworld was using the problematical clang that messes up handling thrown C++ exceptions in the libraries that clang builds. I report problems that I find, which is why I do the experiments.] (In reply to Mark Millard from comment #8) I'm not sure about the constraints. It is definitely possible to test another toolchain if the llvm one does not work. However, we are very low on manpower, so we would need help in maintaining that, and I don't think any of us have a readily accessible ppc[64] system to test with. I'm also not sure what the interaction with mesa ports will be, since they explicitly use llvm. I've just tried to build fresh `graphics/mesa-dri` port on Mac mini G4 running 12.0-CURRENT (albeit pretty old one, around Mid-2016), and it builds and packages fine (it pulls GCC, but since 5.x and 6.x are broken on powerpc, I have GCC_VERSION set to 4.9 for powerpc). No changes were required for the port itself. (In reply to Alexey Dokuchaev from comment #10) This sounds like everything is ok. Do you set the GCC version globally, or does the ports system pick it up automatically? (In reply to Alexey Dokuchaev from comment #10) > it pulls GCC, but since 5.x and 6.x are broken on powerpc What is broken for each of them? The Makefiles are not set up to block building these, which suggests that Mark Linimon's builds have been completing in what looks like a successful status. (He marks things as broken for powerpc64 and for powerpc periodically.) Of course it could be that what is built is still broken in some way at run-time. It is true that, for powerpc64, lang/gcc6 will first cause a lang/gcc5 build in order to bootstrap, avoiding gcc 4.2.1 from the system. The Makefile does not set up such for (32-bit) powerpc . (Should it?) [As I use system-clang in order to find and report problems for targeting powerpc64 and powerpc, my normal powerpc and powerpc64 contexts are not appropriate for tests of such for the officially supported context.] First of all, sorry for inadvertent confusion, GCC situation is not as bad on powerpc as on sparc64. I've had GCC version downgraded on powerpc not because it was broken (I never tried), but because I generally prefer lower versions due to less code bloat, and because I already had gcc-4.9.4.tar.gz2 distfile downloaded (and they are pretty big). Niclas, for now, I had to modify /usr/ports/Mk/bsd.default-versions.mk by hand. Eventually, after I iron out remaining issues with gcc48/49 under sparc64 (it could never finish the build for me under QEMU with BOOSTRAP option enabled, which is the default, so it needs to be flipped), I'd probably submit a patch to set appropriate GCC default version based on particular architecture; this would most likely be applicable to sparc64 and /maybe/ powerpc. That said, I'll rebuild `graphics/mesa-dri' with default gcc version (6?) on powerpc and report again. Mark, sorry, I was thinking of sparc64; both gcc5/6 are marked as broken on it currently. They probably build fine on powerpc, I just haven't tried yet. [I cannot say much about system-clang, I'm quite happy with gcc 4.2 as a system compiler. In fact, that what makes tier-2 architectures more attractive to me now: they don't use clang.] (In reply to Alexey Dokuchaev from comment #13) Have you had any luck recompiling mesa? Feedback timeout. Feel free to open if this is still an issue and/or you have new information about the issue. |
Created attachment 158856 [details] pic of error I was building the xorg-minimal port which depends on dri how ever that failed to build. I was given a patch from someone in the powerpc mailing list for the dri port but that failed as well. I am sending a screenshot of the error and the config.log file.