I’m seeing this error when generate all the header dependencies for FbdReader.
This is confusing, which file has the error?
:info:build In file included from Point.cpp:In file included from In file
included from 1In file included from Element2d.cppFbdReader.cppSeqa.cpp:::1:
:info:build In file included from ../../FbdReader/inc/FbdReader.hxx:
:info:build :127:
:info:build 2In file included from :
:info:build In file included from ../../FbdReader/inc/FbdReader.hxx::
:info:build 27:
:info:build In file included from
/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxxIn file included from
../../FbdReader/inc/FbdReader.hxx../../FbdReader/inc/FbdReader.hxx:27:In file
included from ::
:info:build 24In file included from :
:info:build
/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxx:/opt/local/include/opencascade/BRepLib_MakeWire.hxx:1762427/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxx:
:info:build In file included from ::
:info:build 81:
error/opt/local/include/opencascade/BRepBuilderAPI_MakeWire.hxx: :a space is
required between consecutive right angle brackets (use '> >')24
:info:build :24/opt/local/include/opencascade/BRepLib_MakeWire.hxx:
:info:build :176:/opt/local/include/opencascade/BRepLib_MakeWire.hxx81::176
:error81: :a space is required between consecutive right angle brackets (use '>
>')
:info:build error: a space is required between consecutive right angle brackets
(use '> >')
:info:build
NCollection_List<NCollection_List<TopoDS_Vertex>>& theGrVL);
:info:build
^~
:info:build
> >
:info:build
NCollection_List<NCollection_List<TopoDS_Vertex>>& theGrVL);
NCollection_List<NCollection_List<TopoDS_Vertex>>& theGrVL);
:info:build
^~:
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:176
^~:
:info:build 81
> >:
:info:build error: a space is required between consecutive right angle
brackets (use '> >')
:info:build
> >
:info:build
NCollection_List<NCollection_List<TopoDS_Vertex>>& theGrVL);
:info:build
^~
:info:build
> >
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:178:79: error:
a space is required between consecutive right angle brackets (use '> >')
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx: void
CreateNewVertices(const NCollection_List<NCollection_List<TopoDS_Vertex>>&
theGrVL, 178
:info:build :
^~79
:info:build :
> >
:info:build error: a space is required between consecutive right angle brackets
(use '> >')
:info:build void CreateNewVertices(const
NCollection_List<NCollection_List<TopoDS_Vertex>>& theGrVL,
:info:build
^~
:info:build
> >
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:178:79: error:
a space is required between consecutive right angle brackets (use '> >')
:info:build void CreateNewVertices(const
NCollection_List<NCollection_List<TopoDS_Vertex>>& theGrVL,
:info:build
^~
:info:build
> >
:info:build /opt/local/include/opencascade/BRepLib_MakeWire.hxx:178:79: error:
a space is required between consecutive right angle brackets (use '> >')
:info:build void CreateNewVertices(const
NCollection_List<NCollection_List<TopoDS_Vertex>>& theGrVL,
:info:build
^~
:info:build
> >
Mark Brethen
[email protected]
> On Aug 3, 2022, at 3:51 PM, Mark Brethen <[email protected]> wrote:
>
> I solved the build issue I was having with CadReader. I now have a different
> problem with FbdReader using opencascade 7.6:
>
> :info:build :../../FbdReader/inc/FbdReader.hxx:1074:: 74fatal error::
> 'GeomAdaptor_HCurve.hxx' file not found
> :info:build fatal error10:10: fatal error: 'GeomAdaptor_HCurve.hxx' file not
> found
> :info:build : 'GeomAdaptor_HCurve.hxx' file not found
> :info:build #include <GeomAdaptor_HCurve.hxx>
> :info:build ^~~~~~~~~~~~~~~~~~~~~~~~
> :info:build #include <GeomAdaptor_HCurve.hxx>
> :info:build ^~~~~~~~~~~~~~~~~~~~~~~~
> :info:build #include <GeomAdaptor_HCurve.hxx>
> :info:build ^~~~~~~~~~~~~~~~~~~~~~~~
> :info:build fatal error: 'GeomAdaptor_HCurve.hxx' file not found
> :info:build #include <GeomAdaptor_HCurve.hxx>
> :info:build ^~~~~~~~~~~~~~~~~~~~~~~~
>
> I found this in the release notes:
>> Upgrade to OCCT 7.6.0
>>
>> <>Simplification of surface/curve adaptor
>>
>> Interfaces Adaptor2d_Curve2d
>> <https://dev.opencascade.org/doc/refman/html/class_adaptor2d___curve2d.html>,
>> Adaptor3d_Curve
>> <https://dev.opencascade.org/doc/refman/html/class_adaptor3d___curve.html>
>> and Adaptor3d_Surface
>> <https://dev.opencascade.org/doc/refman/html/class_adaptor3d___surface.html>
>> now inherit Standard_Transient
>> <https://dev.opencascade.org/doc/refman/html/class_standard___transient.html>
>> and can be Handle-managed. No more necessary parallel hiererchy of classes
>> Adaptor2d_HCurve2d, Adaptor3d_HCurve and Adaptor3d_HSurface (generated from
>> generic templates by WOK) has been eliminated. Existing code using old
>> Handle classes should be updated to:
>>
>> Rename occurrences of old names (remove H suffix); upgrade.bat could be used
>> for that purpose.
>> Replace redundant calls to previously declared methods
>> .GetCurve2d()/.GetCurve()/.GetSurface() with the common operator->() syntax.
>> Pay attention on code calling GetSurface()/GetCurve() methods of removed
>> handle classes. Such places should be replaced with Handle dereference.
>
> I'll try patching the source.
>
> Thanks,
> Mark
> Mark Brethen
> [email protected] <mailto:[email protected]>
>
>
>
>> On Aug 3, 2022, at 10:18 AM, Mark Brethen <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> It turns out the headers were their, I just didn’t have access due to a
>> permissions setting on the ‘inc’ directory itself. There are quite a few
>> undefined symbols listed in the build log.
>>
>> https://pastebin.com/dh1Wx67C <https://pastebin.com/dh1Wx67C>
>>
>>
>> Mark Brethen
>> [email protected] <mailto:[email protected]>
>>
>>
>>
>>> On Aug 3, 2022, at 2:21 AM, Mark Brethen <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> I confirmed the bzip file contains the header files, however, the files are
>>> missing in the workpath. And there is nothing unusual in the log to explain
>>> what happened.
>>>
>>> <main.log>
>>>
>>>
>>> Mark Brethen
>>> [email protected] <mailto:[email protected]>
>>>
>>>
>>>
>>>> On Aug 2, 2022, at 6:20 PM, Robert Kennedy <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Mark,
>>>>
>>>> I was able to spend more time with your Makefile. I corrected some typos.
>>>>
>>>> Attached is the FINAL Makefile Rev 4 along with the patch file (that will
>>>> patch the original Makefile)
>>>>
>>>> It should work well for your purposes.
>>>>
>>>> If you are having trouble with the extraction phase, please send me a copy
>>>> of your Portfile and I will take a look. It can be frustrating when
>>>> things do not unpack as expected.\\
>>>>
>>>> Rob
>>>>
>>>> From: Mark Brethen <[email protected] <mailto:[email protected]>>
>>>> Sent: August 2, 2022 4:51 PM
>>>> To: Robert Kennedy <[email protected] <mailto:[email protected]>>
>>>> Cc: MacPorts Developers <[email protected]
>>>> <mailto:[email protected]>>
>>>> Subject: Re: include files for cgxCADTools
>>>>
>>>> I found the issue: There should be header files in
>>>> ‘${workpath}/cgxCadTools/CadReader/inc’ but for some reason the extract
>>>> phase is omitting them, i.e. the ‘inc’ directory is empty.
>>>>
>>>> Why would it be doing this?
>>>>
>>>>
>>>> Mark Brethen
>>>> [email protected] <mailto:[email protected]>
>>>>
>>>>
>>>>
>>>>> On Aug 2, 2022, at 2:52 PM, Robert Kennedy <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> I missed one. You also need to change:
>>>>>
>>>>> $(CC) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
>>>>>
>>>>> to
>>>>>
>>>>> $(CCX) $(LDFLAGS) $(INCLUDES) -o $(MAIN) $(OBJS) $(LFLAGS) $(LIBS)
>>>>>
>>>>> Rob
>>>>> From: Robert Kennedy <[email protected] <mailto:[email protected]>>
>>>>> Sent: August 2, 2022 3:46 PM
>>>>> To: Mark Brethen <[email protected] <mailto:[email protected]>>
>>>>> Subject: Re: include files for cgxCADTools
>>>>>
>>>>> Mark,
>>>>>
>>>>> Since it is a C++ project (not a C project), I modified the Makefile
>>>>> accordingly. See attached.
>>>>>
>>>>> Please note that I added LDFLAGS = -stdlib=libc++ and added $LDFLAGS to
>>>>> the Makefile target that does the linking.
>>>>>
>>>>> This is needed so the code will link properly on older macs (like my old
>>>>> Mac running Lion).
>>>>>
>>>>> Alternatively, you could add the following to the Portfile:
>>>>> configure.ldflags-append "-stdlib=${configure.cxx_stdlib}"
>>>>>
>>>>> Rob
>>>>>
>>>>> From: Robert Kennedy <[email protected] <mailto:[email protected]>>
>>>>> Sent: August 2, 2022 3:03 PM
>>>>> To: Mark Brethen <[email protected] <mailto:[email protected]>>
>>>>> Subject: Re: include files for cgxCADTools
>>>>>
>>>>> I forgot to mention that I normally change all the CFLAGS and LDFLAGS as
>>>>> follows:
>>>>>
>>>>> CFLAGS = blah blah
>>>>> CFLAGS += blah blah
>>>>>
>>>>> This will allow Macports to add its own flags.
>>>>>
>>>>> You do not need to do that with CC or CCX.
>>>>>
>>>>> Rob
>>>>> From: Robert Kennedy <[email protected] <mailto:[email protected]>>
>>>>> Sent: August 2, 2022 3:00 PM
>>>>> To: Mark Brethen <[email protected] <mailto:[email protected]>>
>>>>> Subject: Re: include files for cgxCADTools
>>>>>
>>>>> Mark,
>>>>>
>>>>> I could not get the patch file to patch the Makefile. So I manually
>>>>> applied the patches. And added my changes.
>>>>>
>>>>> Attached please find the FINAL Makefile and a patch file showing all the
>>>>> diffs (including yours) from the original Makefile.
>>>>>
>>>>> I also did the following:
>>>>> Deleted all the dependencies, generated by makedepend below the "# DO NOT
>>>>> DELETE THIS LINE -- make depend needs it" line.
>>>>> Added "macports" to .PHONY (P.S. PHONY targets provide rules that do
>>>>> not directly build or link real binary objects. They call on other
>>>>> targets that build and link the actual code).
>>>>> Added the "macports" target:
>>>>> macports: depend all
>>>>> The rule for the Macports target is:
>>>>>
>>>>> macports: depend all
>>>>>
>>>>> When make macports is run, it will first run the "depend" target in the
>>>>> Makefile and generate all the header dependencies and then it will run
>>>>> the "all" target to build and link the code.
>>>>>
>>>>> Now you have two choices as far as Macports is concerned:
>>>>> Just use the Makefile as is and see if the code builds and links. It
>>>>> likely will unless you are missing a header directory in $(INCLUDES). OR
>>>>> Add the following to the Portfile which causes makedepend to run (which
>>>>> will generate all those dependencies) before compiling and linking the
>>>>> code:
>>>>> depends_build port:makedepend
>>>>> build.target macports
>>>>> If the Makefile is doing all the building and linking for your Project,
>>>>> you should probably also add the following to the Portfile:
>>>>>
>>>>> PortGroup makefile 1.0
>>>>>
>>>>> I am working with a similar Makefile. Both approaches above work for me.
>>>>> Approach 1 runs a lot faster since it does not call on makedependto
>>>>> generate all those header dependencies (which can take some time for a
>>>>> large project). And as mentioned in my previous posts to the Macports
>>>>> mailing list, the compiler typically does NOT need to know about these
>>>>> header dependencies to properly build and link the final binary product
>>>>> for the first time.
>>>>>
>>>>> But the compiler does need to know the location of all the directories
>>>>> where all the non-system headers can be found so when it processes an
>>>>> #include in a source file, it can find the needed header. The
>>>>> $(INCLUDES) does not need to contain any of the directories where the
>>>>> system headers are located since the compiler knows where they are. And
>>>>> as you found out, the location of the system headers will change from
>>>>> MacOS to MacOS.
>>>>>
>>>>> I went with Approach 1 for my project.
>>>>>
>>>>> P.S. It looks like the project is using autotools or cmake to generate
>>>>> the Makefile so you likely need to patch the Makefile at the end of the
>>>>> configure stage or before building. The most important thing is deleting
>>>>> all those header dependencies at the end of the Makefile.
>>>>>
>>>>> Good Luck.
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>> From: Mark Brethen <[email protected]
>>>>> <mailto:[email protected]>>
>>>>> Sent: August 2, 2022 1:34 PM
>>>>> To: Robert Kennedy <[email protected] <mailto:[email protected]>>
>>>>> Subject: Re: include files for cgxCADTools
>>>>>
>>>>> Rob,
>>>>>
>>>>> There is the line '.PHONY: depend clean' but 'make all’ only calls
>>>>> $(MAIN).
>>>>>
>>>>> Thanks,
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>>> On Aug 2, 2022, at 9:34 AM, Robert Kennedy <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>> Mark,
>>>>>>
>>>>>> To be clear, I would first try patching the Makefile by deleting all the
>>>>>> system header dependencies from the Makefile and then see if Macports
>>>>>> will build the project. But make sure the Makefile lists the location
>>>>>> of all the directories where the header files are located. (I typically
>>>>>> place them in $(INCLUDES)). And make sure the rules contain $(INCLUDES).
>>>>>>
>>>>>> You typically do not need to list the directories of the system header
>>>>>> files because the compiler typically knows where they are (which as you
>>>>>> know may change from MacOS to MacOS).
>>>>>>
>>>>>> If you want to know why, keep reading....
>>>>>>
>>>>>> Typically "make" only needs to know the following to build the initial
>>>>>> Project from scratch:
>>>>>> The rules that define what source code files are needed to build each
>>>>>> object and a rule for linking the object files and the location of the
>>>>>> directories for the header files (e.g. main.h).
>>>>>> e.g
>>>>>>
>>>>>> INCLUDES := -I./
>>>>>>
>>>>>> .PHONY all
>>>>>>
>>>>>> all: edit
>>>>>>
>>>>>> edit: main.o kdb.o
>>>>>> $(CC) $(LDFLAGS) -o main.o kbd.o
>>>>>>
>>>>>> main.o: main.c myfunc.c
>>>>>> $(CC) $(CFLAGS) $(INCLUDES) -c main.c myfunc.c
>>>>>>
>>>>>> kbd.o: kbd.c
>>>>>> $(CC) $(CFLAGS) $(INCLUDES) -c kbd.c
>>>>>>
>>>>>>
>>>>>> In the example above, the directories of the header files are in listed
>>>>>> in $(INCLUDES).
>>>>>>
>>>>>> You do not need to list the directories of the system header files in
>>>>>> $(INCLUDES) because the compiler knows where they are (which as you know
>>>>>> may change from MacOS to MacOS).
>>>>>>
>>>>>> Ideally, if you know that a particular header is a dependency for an
>>>>>> object, it is better to list it in the rule (e.g. main.o: main.c
>>>>>> myfunc.c main.h) OR create a separate rule for the header dependency:
>>>>>>
>>>>>> main.o: main.h
>>>>>>
>>>>>> But these header dependency rules are typically not needed to build the
>>>>>> initial project from scratch! These rules exist so "make" will only
>>>>>> rebuild the minimum number of objects when a header file has changed.
>>>>>>
>>>>>> E.g. If I change header.h and then run "make all" again in the above
>>>>>> example, make will only recompile main.o and then it will link main.o
>>>>>> with the previously built kbd.o. kbd.o does not need to be recompiled.
>>>>>> This saves time. Great for development!
>>>>>>
>>>>>> Macports does not do this. It typically will rebuild the whole project
>>>>>> from scratch. (i.e. build all the objects and then link them into the
>>>>>> final product).
>>>>>>
>>>>>> In my view, Macports was not designed for development but for building a
>>>>>> finished project and making a binary package. (i.e. package management)
>>>>>>
>>>>>> If you are still having problems, please EMAIL me the Makefile and I
>>>>>> will take a look.
>>>>>>
>>>>>> RobK88
>>>>>> From: macports-dev <[email protected]
>>>>>> <mailto:[email protected]>> on behalf of Robert
>>>>>> Kennedy <[email protected] <mailto:[email protected]>>
>>>>>> Sent: August 2, 2022 8:10 AM
>>>>>> To: Mark Brethen <[email protected]
>>>>>> <mailto:[email protected]>>; MacPorts Developers
>>>>>> <[email protected]
>>>>>> <mailto:[email protected]>>
>>>>>> Subject: Re: include files for cgxCADTools
>>>>>>
>>>>>> Mark,
>>>>>>
>>>>>> I agree with Josh, these headers look like they were automatically
>>>>>> generated using something like "make depends".
>>>>>>
>>>>>> When creating a Makefile, it is GOOD practice to include these lines as
>>>>>> it will ensure that the Project will rebuild the correct files when a
>>>>>> header file was changed. Since it is a REAL pain to create them
>>>>>> manually. Many developers use something like "make depends".
>>>>>>
>>>>>> If there is a "depends:" target in the Makefile, you could patch the
>>>>>> Makefile and add "depends" as the first Phony target to the "all:"
>>>>>> target. e.g.
>>>>>>
>>>>>> all: depends main etc etc
>>>>>>
>>>>>> Alternatively, you could try just patching the Makefile by removing all
>>>>>> these lines (and any other line where a system header is the ONLY
>>>>>> dependency in the rule). The vast majority of time, they are NOT needed
>>>>>> to build the initial project. (They are needed if you want to use
>>>>>> "make" to rebuild your project properly on subsequent runs where the
>>>>>> developer has changed one of more of these system header files. This is
>>>>>> not a normal scenario if one is using Macports to build the project).
>>>>>>
>>>>>> The most important rules are the rules involving the source code files
>>>>>> (which must be kept).
>>>>>> e.g. $(OBJDIR-MAIN)/%.o: %.c
>>>>>> $(CC) $(CFLAGS) $(INCLUDES) -c $< -o $@
>>>>>>
>>>>>> Make sure the Makfile has an "INCLUDES:" that lists the location of all
>>>>>> the header files. If it does, make will find them and build the initial
>>>>>> project!
>>>>>>
>>>>>> e.g. I am working on a new port where I converted an Xcode project to
>>>>>> one using a Makefile. I used "make depends" to generate these
>>>>>> dependencies, Macports built the code just fine when I either:
>>>>>> Deleted all the lines below "# DO NOT DELETE THIS LINE -- make depend
>>>>>> needs it"; or
>>>>>> Added "depends" as the first phony target to the all: phoney target
>>>>>> e.g. all: depends utils altivec mpeg2enc main $(PRODUCT)
>>>>>>
>>>>>> You could even patch the Makefile and add another target called
>>>>>> "macports" and tell Macports to build that:
>>>>>>
>>>>>> macports: depends all
>>>>>>
>>>>>> And in the portfile, you would add:
>>>>>>
>>>>>> build.target macports
>>>>>>
>>>>>> Good luck,
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>> From: macports-dev <[email protected]
>>>>>> <mailto:[email protected]>> on behalf of Mark
>>>>>> Brethen <[email protected] <mailto:[email protected]>>
>>>>>> Sent: August 1, 2022 8:51 PM
>>>>>> To: MacPorts Developers <[email protected]
>>>>>> <mailto:[email protected]>>
>>>>>> Subject: Re: include files for cgxCADTools
>>>>>>
>>>>>> I’ll ask the developer
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> > On Aug 1, 2022, at 4:53 PM, Joshua Root <[email protected]
>>>>>> > <mailto:[email protected]>> wrote:
>>>>>> >
>>>>>> > A lot of them aren't even standard headers; I believe the ones under
>>>>>> > bits/ are glibc implementation details. I would suspect this part of
>>>>>> > the Makefile was not hand-written but generated with one of the
>>>>>> > compiler's -M options. To work correctly in that case, it would need
>>>>>> > to be regenerated for each new system the software is built on.
>>>>>> >
>>>>>> > - Josh
>>>>>> >
>>>>>> >> On 2022-8-2 05:23 , Chris Jones wrote:
>>>>>> >> The makefile here is very poorly written. You should never directly
>>>>>> >> reference standard headers like that…
>>>>>> >>>> On 1 Aug 2022, at 4:52 pm, Mark Brethen <[email protected]
>>>>>> >>>> <mailto:[email protected]>> wrote:
>>>>>> >>>
>>>>>> >>> This Makefile has the following lines:
>>>>>> >>>
>>>>>> >>> CadReader.o: /usr/include/stdlib.h
>>>>>> >>> /usr/include/bits/libc-header-start.h
>>>>>> >>> CadReader.o: /usr/include/features.h /usr/include/stdc-predef.h
>>>>>> >>> CadReader.o: /usr/include/sys/cdefs.h /usr/include/bits/wordsize.h
>>>>>> >>> CadReader.o: /usr/include/bits/long-double.h /usr/include/gnu/stubs.h
>>>>>> >>> CadReader.o: /usr/include/bits/waitflags.h
>>>>>> >>> /usr/include/bits/waitstatus.h
>>>>>> >>> CadReader.o: /usr/include/bits/floatn.h /usr/include/sys/types.h
>>>>>> >>> CadReader.o: /usr/include/bits/types.h /usr/include/bits/typesizes.h
>>>>>> >>> CadReader.o: /usr/include/bits/types/clock_t.h
>>>>>> >>> CadReader.o: /usr/include/bits/types/clockid_t.h
>>>>>> >>> CadReader.o: /usr/include/bits/types/time_t.h
>>>>>> >>> CadReader.o: /usr/include/bits/types/timer_t.h
>>>>>> >>> CadReader.o: /usr/include/bits/stdint-intn.h /usr/include/endian.h
>>>>>> >>> CadReader.o: /usr/include/bits/endian.h /usr/include/bits/byteswap.h
>>>>>> >>> CadReader.o: /usr/include/bits/byteswap-16.h
>>>>>> >>> CadReader.o: /usr/include/bits/uintn-identity.h
>>>>>> >>> /usr/include/sys/select.h
>>>>>> >>> CadReader.o: /usr/include/bits/select.h
>>>>>> >>> /usr/include/bits/types/sigset_t.h
>>>>>> >>> CadReader.o: /usr/include/bits/types/__sigset_t.h
>>>>>> >>> CadReader.o: /usr/include/bits/types/struct_timeval.h
>>>>>> >>> CadReader.o: /usr/include/bits/types/struct_timespec.h
>>>>>> >>> CadReader.o: /usr/include/sys/sysmacros.h
>>>>>> >>> /usr/include/bits/sysmacros.h
>>>>>> >>> CadReader.o: /usr/include/bits/pthreadtypes.h
>>>>>> >>> CadReader.o: /usr/include/bits/thread-shared-types.h
>>>>>> >>> CadReader.o: /usr/include/bits/pthreadtypes-arch.h
>>>>>> >>> /usr/include/alloca.h
>>>>>> >>> CadReader.o: /usr/include/bits/stdlib-float.h
>>>>>> >>>
>>>>>> >>> /usr/include doesn’t exist on Big Sure (I assume its deprecated?)
>>>>>> >>> however, they can be found at
>>>>>> >>>
>>>>>> >>> ~ $ xcrun --sdk macosx --show-sdk-path
>>>>>> >>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk
>>>>>> >>>
>>>>>> >>> although I don’t see a ‘bits’ subdirectory. Has it been relocated?
>>>>>> >>>
>>>>>> >>> Thanks,
>>>>>> >>> Mark
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >
>>>>
>>>> <Final-Combined-Makefile-Patches - Rev 2.diff><Makefile FINAL-Rev4>
>>>
>>
>
