https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123976
--- Comment #151 from Peter Dyballa <Peter_Dyballa at web dot de> ---
(In reply to Iain Sandoe from comment #149)
> (In reply to Peter Dyballa from comment #148)
> > D-word! Breakfast is ready to be eaten and the build stops with missing
> > md-unwind-def.h!
>
> so you are saying with the exact same sources as I provided ... but with
> your local tools and that complex configuration line, it fails?
Yes, it failed as usual
>
> > Before I start another, a bit more optimised build with updated PATH
> > setting, how can I start to build the cross-compiler up to the final stages
> > of all four, ppc(32), i686, x86_64, ppc64? Probably it's necessary to now
> > enable multilib…
>
> please work on reducing the complexity not increasing it....
It would be an opportunity to find possibly more bugs. Me, I also want to
understand what makes building in <architecture>/gcclib different for each
hardware architecture. Naming the differences would help to find make rules,
would help to find definitions of these rules, would allow to check the code. I
do not see that much additional complexity, it's just three additional builds
that might adhoc succeed.
If they do so than we'll have a proof that it's only a ppc and not a darwin9
problem.
>
> I think that this is not a direction that is going to work - the discrepancy
> is not in the sources, right?
Yes, it's in make or the Makefiles. Did we compare the Makefiles yet? Or some
debug output from make?
>
> $ find . -name md-\*
> ./powerpc-apple-darwin9/libgcc/md-unwind-def.h
> ./powerpc-apple-darwin9/libgcc/md-unwind-support.h
> ./prev-powerpc-apple-darwin9/libgcc/md-unwind-def.h
> ./prev-powerpc-apple-darwin9/libgcc/md-unwind-support.h
> ./stage1-powerpc-apple-darwin9/libgcc/md-unwind-def.h
> ./stage1-powerpc-apple-darwin9/libgcc/md-unwind-support.h
>
leopard pete 233 /\ find . -name md-\* -ls
139301787 8 lrwxr-xr-x 1 pete admin 33 2 Jul 10:42
./powerpc-apple-darwin9/libgcc/md-unwind-support.h ->
../.././libgcc/config/no-unwind.h
> $ find . -name unwind-dw2.o
> ./powerpc-apple-darwin9/libgcc/unwind-dw2.o
> ./prev-powerpc-apple-darwin9/libgcc/unwind-dw2.o
> ./stage1-powerpc-apple-darwin9/libgcc/unwind-dw2.o
leopard pete 234 /\ find . -name unwind-dw2.o -ls ==> nothing
>
> So .. what is the output of
>
> which make
> make --version
leopard pete 235 /\ which make
/usr/bin/make
leopard pete 236 /\ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for powerpc-apple-darwin9.0
> I don't suppose that there's any chance of me persuading you that the right
> way to find the problem is to back out of all the complexity until you have
> a working build and then find out which addition is causing the problem?
What do you mean with "addition"?
On something different! When I checked the MacPorts symlinks the utility
symlinks showed that inside the finished (yet untested) GCC-16.1 build *with*
MacPorts two dangling links were found. While I was answering your questions
symlinks ran in gcc-16-branch-gcc-16-1-darwin, i.e. the recent build directory.
It found:
dangling:
gcc-16-branch-gcc-16-1-darwin/host-powerpc-apple-darwin9/gcc/include-fixed/c++/4.0.0/i686-apple-darwin8
-> ../../c++/4.0.0/i686-apple-darwin9
dangling:
gcc-16-branch-gcc-16-1-darwin/host-powerpc-apple-darwin9/gcc/include-fixed/c++/4.0.0/powerpc-apple-darwin8
-> ../../c++/4.0.0/powerpc-apple-darwin9
find . \( -name i686-apple-darwin8 -o -name powerpc-apple-darwin9 \) -ls? yes
139301277 8 lrwxr-xr-x 1 pete admin 34 2 Jul 10:39
./host-powerpc-apple-darwin9/gcc/include-fixed/c++/4.0.0/i686-apple-darwin8 ->
../../c++/4.0.0/i686-apple-darwin9
139284968 0 drwxr-xr-x 3 pete admin 102 2 Jul 10:41
./powerpc-apple-darwin9
leopard pete 238 /\ port info symlinks
symlinks @1.4.3 (sysutils)
Variants: universal
Description: Scans directories for symbolic links, and identifies
dangling, relative, absolute, messy, and other_fs links. Can optionally change
absolute links to relative within a given filesystem. Recommended for use by
anyone developing and/or maintaining a Linux FTP site or
distribution or CD-ROM.
Homepage: https://github.com/brandt/symlinks
Platforms: darwin
License: MIT
Maintainers: Email: [email protected], GitHub: fracai
Policy: openmaintainer