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

Reply via email to