[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sr #111158] 'make check' fails on older Mac, especially when building f
From: |
Ileana Dumitrescu |
Subject: |
[sr #111158] 'make check' fails on older Mac, especially when building fat binaries |
Date: |
Tue, 10 Dec 2024 13:05:45 -0500 (EST) |
Follow-up Comment #1, sr #111158 (group libtool):
Thank you for your bug report and sharing your findings.
[comment #0 original submission:]
> I'm using a Power Mac G5 with Mac OS 10.5.8 (Darwin 9.8). My package manager
> massages the build environment a bit to ensure consistent behaviour. Part of
> that involves ensuring that compiler runs always get "-arch xxxx" flags
> inserted when a 64-bit or universal binary is being built (an absolute
> requirement, because otherwise extension modules and test programs do not
> necessarily get built with the same architecture as the rest of the package,
> which causes immediate failure when (for example) a 64-bit program tries to
> link to a 32-bit plug-in bundle, or the like). In this environment,
> libtool's test suite exhibits three incorrect failures and one incorrect
> skip. I believe that three of the four would still occur without it.
>
> Test 95, for localization, artificially fails because it does not know to
> ignore the additional error message from the 'lipo' tool that follows the
> expected compiler error.
If you could supply the error from the 'lipo' tool, I could update the test to
ignore it.
> Test 119, with the enforced library prefix, fails because the linker refuses
> to link an extension bundle (Mach filetype MH_BUNDLE) to a dynamic library
> (Mach filetype MH_DYLIB). I have yet to determine whether this is due to the
> somewhat outdated native linker, or to a formal policy inherent to Mac OS.
>
> Test 161, the Darwin fat compile, is incorrectly skipped. As far as I can
> tell this is gated by a very straightforward test for the string 'darwin'
> appearing in the OS name (which it does, according to the logs), so how it is
> deciding to skip that is a mystery to me.
Could it be skipping due to a different part of the test?
> Test 172, which repeats a large subset of the entire test suite with a
> shorter maximum command line length, incorrectly reports failure when the
> only failed tests are the same ones that failed at normal line lengths. If
> nothing changed, this should not be reporting a failure.
This will resolve itself when the other tests are passing, so I would just
ignore this failure.
For all of the tests mentioned, it would be useful to view each testsuite.log
from them. These can be found in the individual test directories, for example
libtool/testsuite.dir/095/testsuite.log. When executing the testsuite with
'make check', you can pass TESTSUITEFLAGS="--debug" to retain the logs from
tests run.
Also, the output from 'libtool --config' may help with understanding some of
these test failures/skips.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/support/?111158>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature