Re: Configuring GCC 10.3 on PPC Mac OS X 10.4.11/Tiger for build reveals problems when removing relics

[Iain Sandoe <iain@sandoe.co.uk>]

Hi Pete,

> On 25 Nov 2022, at 10:36, Peter Dyballa via Gcc <gcc@gcc.gnu.org> wrote:

> On Mac OS X/macOS configure scripts leave conftest.dSYM subdirectories behind, created by dsymutil:
> 
> 	checking for build system preprocessor... rm: conftest.dSYM: is a directory
> 	checking for build system executable suffix... rm: conftest.dSYM: is a directory
> 	checking whether build system compiler is ANSI... rm: conftest.dSYM: is a directory
> 	checking for build system compiler math library... rm: conftest.dSYM: is a directory
> 
> Building GCC 10.3 with MacPorts the configure scripts produce 178 such reports (and more than 11,000 checking lines without complaint). (The relation is worse when building smaller software packages.)

I agree it’s an irritation (although not a show-stopper, so other things are higher priority right now on my list).

> Is it possible to replace the simple "rm" with "rm -r", at least on darwin, the macOS/Mac OS X? Or create a special macro to be used when dsymutil gets involved?

It is likely to be possible, where the configure tests can be modified in the GCC sources.

The best course of action is to take them one by one and see where the configure source comes from, go to that source and modify the rm (hopefully, conditionally on *-*-darwin*) to deal with this.  If the source of the problems is primarily libtool.m4 … then we do make local modifications, but now that (libtool) is maintained again we should look into how much we can sync with upstream.

I’m happy to review patches (if they are macOS/darwin-specific, then I can even approve them).

Iain

> 
> --
> 
> Greetings
> 
>  Pete
> 
> Every instructor assumes that you have nothing else to do except study for that instructor's course. 
> 				– Fourth Law of Applied Terror
>