#66062 closed defect (fixed)
libgcc12: build failure: error: use of undeclared identifier 'PTR'
Reported by: | i0ntempest | Owned by: | i0ntempest |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.8.0 |
Keywords: | Cc: | jpchauvel (Jean-Pierre Chauvel) | |
Port: | libgcc12, gcc12, |
Description (last modified by i0ntempest)
This is on macOS 13 with Xcode/CLT 14.1 RC. I think there's a conflict with another port somewhere, because on another one of my macs with a lot fewer ports installed, libgcc12 was able to be built.
:info:build /usr/bin/clang -arch x86_64 -c -DHAVE_CONFIG_H -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -I. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc12/libgcc12/work/gcc-12.2.0/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc12/libgcc12/work/gcc-12.2.0/libiberty/lrealpath.c -o lrealpath.o :info:build checking for vfork... /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc12/libgcc12/work/gcc-12.2.0/libiberty/objalloc.c:95:18: error: use of undeclared identifier 'PTR' :info:build ret->chunks = (PTR) malloc (CHUNK_SIZE); :info:build
Attachments (1)
Change History (9)
Changed 2 years ago by i0ntempest
comment:1 Changed 2 years ago by i0ntempest
Description: | modified (diff) |
---|
comment:2 Changed 2 years ago by kencu (Ken)
comment:3 Changed 2 years ago by i0ntempest
binutils it is. Should we add it into gcc port file as a build conflict?
comment:4 Changed 2 years ago by kencu (Ken)
I can't, unfortunately, think of anything more elegant to do about it.
But who knows how many ports might be affected by this? Could be many. It would be kinda nice to see just what is pulling that binutils header and if we could, figure how to stop that from happening for all of them....
so for now conflicting the ones we do find is all I can come up with.
comment:5 Changed 2 years ago by jpchauvel (Jean-Pierre Chauvel)
Cc: | jpchauvel added |
---|
comment:6 Changed 2 years ago by i0ntempest
Owner: | set to i0ntempest |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:7 follow-up: 8 Changed 2 years ago by jmroot (Joshua Root)
Installing binutils in a separate prefix might be the approach to use to stop things from accidentally using it.
I think someone noted something like this when binutils was installed.