Mark,
You could be missing a header file or maybe a flag to the linker/compiler for a
particular library (e.g. -lm).
P.S. Here is a tip. For older Macs, like those running Lion, one often needs
to add the following to the Portfile to ensure that the linker will link
against stdc++:
configure.ldflags-append "-stdlib=${configure.cxx_stdlib}
If you do not include it, one will often see the following when trying to build
and link on the older Macs:
ld: symbol(s) not found for architecture x86_64
Rob
________________________________
From: Mark Brethen <[email protected]>
Sent: August 2, 2022 3:00 PM
To: Robert Kennedy <[email protected]>
Cc: MacPorts Developers <[email protected]>
Subject: Re: include files for cgxCADTools
I stripped those lines but there were some glitches in the build. First the
Makefile only defines CC but the source is c++.
:info:build /opt/local/include/opencascade/Standard_Handle.hxx:75:19: warning:
rvalue references are a C++11 extension [-Wc++11-extensions]
Second, I’m missing an include somewhere.
:info:build plotTopology() in CadReader.o
:info:build std::__1::basic_stringstream<char,
std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_stringstream()
in CadReader.o
:info:build ...
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see
invocation)
:info:build make: *** [tmain] Error 1
https://pastebin.com/9xYCd74R
Mark Brethen
[email protected]<mailto:[email protected]>
On Aug 2, 2022, at 12:34 PM, Mark Brethen
<[email protected]<mailto:[email protected]>> wrote:
Rob,
There is the line '.PHONY: depend clean' but 'make all’ only calls $(MAIN).
<Makefile>
<patch-CadReader-build.diff>
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:
1. 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:
1. Deleted all the lines below "# DO NOT DELETE THIS LINE -- make depend
needs it"; or
2. 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
>>>
>>>
>>>
>
