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 mark.bret...@gmail.com > On Aug 3, 2022, at 3:51 PM, Mark Brethen <mark.bret...@gmail.com> 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 > mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> > > > >> On Aug 3, 2022, at 10:18 AM, Mark Brethen <mark.bret...@gmail.com >> <mailto:mark.bret...@gmail.com>> 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 >> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> >> >> >> >>> On Aug 3, 2022, at 2:21 AM, Mark Brethen <mark.bret...@gmail.com >>> <mailto:mark.bret...@gmail.com>> 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 >>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> >>> >>> >>> >>>> On Aug 2, 2022, at 6:20 PM, Robert Kennedy <am...@hotmail.com >>>> <mailto:am...@hotmail.com>> 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 <mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>> >>>> Sent: August 2, 2022 4:51 PM >>>> To: Robert Kennedy <am...@hotmail.com <mailto:am...@hotmail.com>> >>>> Cc: MacPorts Developers <macports-dev@lists.macports.org >>>> <mailto:macports-dev@lists.macports.org>> >>>> 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 >>>> mark.bret...@gmail.com <mailto:mark.bret...@gmail.com> >>>> >>>> >>>> >>>>> On Aug 2, 2022, at 2:52 PM, Robert Kennedy <am...@hotmail.com >>>>> <mailto:am...@hotmail.com>> 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 <am...@hotmail.com <mailto:am...@hotmail.com>> >>>>> Sent: August 2, 2022 3:46 PM >>>>> To: Mark Brethen <mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>> >>>>> 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 <am...@hotmail.com <mailto:am...@hotmail.com>> >>>>> Sent: August 2, 2022 3:03 PM >>>>> To: Mark Brethen <mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>> >>>>> 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 <am...@hotmail.com <mailto:am...@hotmail.com>> >>>>> Sent: August 2, 2022 3:00 PM >>>>> To: Mark Brethen <mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>> >>>>> 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 <mark.bret...@gmail.com >>>>> <mailto:mark.bret...@gmail.com>> >>>>> Sent: August 2, 2022 1:34 PM >>>>> To: Robert Kennedy <am...@hotmail.com <mailto:am...@hotmail.com>> >>>>> 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 <am...@hotmail.com >>>>>> <mailto:am...@hotmail.com>> 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 <macports-dev-boun...@lists.macports.org >>>>>> <mailto:macports-dev-boun...@lists.macports.org>> on behalf of Robert >>>>>> Kennedy <am...@hotmail.com <mailto:am...@hotmail.com>> >>>>>> Sent: August 2, 2022 8:10 AM >>>>>> To: Mark Brethen <mark.bret...@gmail.com >>>>>> <mailto:mark.bret...@gmail.com>>; MacPorts Developers >>>>>> <macports-dev@lists.macports.org >>>>>> <mailto:macports-dev@lists.macports.org>> >>>>>> 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 <macports-dev-boun...@lists.macports.org >>>>>> <mailto:macports-dev-boun...@lists.macports.org>> on behalf of Mark >>>>>> Brethen <mark.bret...@gmail.com <mailto:mark.bret...@gmail.com>> >>>>>> Sent: August 1, 2022 8:51 PM >>>>>> To: MacPorts Developers <macports-dev@lists.macports.org >>>>>> <mailto:macports-dev@lists.macports.org>> >>>>>> 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 <j...@macports.org >>>>>> > <mailto:j...@macports.org>> 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 <mark.bret...@gmail.com >>>>>> >>>> <mailto:mark.bret...@gmail.com>> 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> >>> >> >