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 > On Aug 3, 2022, at 10:18 AM, Mark Brethen <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> >> >
