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