environment settings

[Mark Brethen]

I’m using the compilers group with

compilers.choose cc f77
compilers.setup require_fortran

below is the env settings:

:debug:configure Environment:
:debug:configure CC='/usr/bin/clang'
:debug:configure CC_PRINT_OPTIONS='YES'
:debug:configure CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_marbre_ports_math_taucs/taucs/work/.CC_PRINT_OPTIONS'
:debug:configure CFLAGS='-pipe -Os -arch x86_64'
:debug:configure CPATH='/opt/local/include'
:debug:configure CPPFLAGS='-I/opt/local/include'
:debug:configure CXX='/usr/bin/clang++'
:debug:configure CXXFLAGS='-pipe -Os -stdlib=libc++ -arch x86_64'
:debug:configure F77='/opt/local/bin/gfortran-mp-8'
:debug:configure F77FLAGS='-m64'
:debug:configure F90FLAGS='-pipe -Os -m64'
:debug:configure FCFLAGS='-pipe -Os -m64'
:debug:configure FFLAGS='-pipe -Os'
:debug:configure INSTALL='/usr/bin/install -c'
:debug:configure LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
:debug:configure LIBRARY_PATH='/opt/local/lib'
:debug:configure MACOSX_DEPLOYMENT_TARGET='10.12'
:debug:configure OBJC='/usr/bin/clang'
:debug:configure OBJCFLAGS='-pipe -Os -arch x86_64'
:debug:configure OBJCXX='/usr/bin/clang++'
:debug:configure OBJCXXFLAGS='-pipe -Os -stdlib=libc++ -arch x86_64'

for this particular port, I need to override the build and pass F77 as the linker. I tried

build.args-append CC=${configure.cc} \
F77=${configure.f77}

build.target lib/${os.platform}${os.major}/libtaucs.a

build {
ui_info "Building libtaucs archives:"
system -W ${worksrcpath} "${build.cmd} ${build.args} ${build.target}"
}

with 'FC= $(F77)’ in the Makefile, but that didn’t work. How should I pass this during build?

Mark Brethen
***@gmail.com

[Ryan Schmidt]

(resent with correction)
I’m using the compilers group with
compilers.choose cc f77
compilers.setup require_fortran
:debug:configure CC='/usr/bin/clang'
:debug:configure CC_PRINT_OPTIONS='YES'
:debug:configure CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_marbre_ports_math_taucs/taucs/work/.CC_PRINT_OPTIONS'
:debug:configure CFLAGS='-pipe -Os -arch x86_64'
:debug:configure CPATH='/opt/local/include'
:debug:configure CPPFLAGS='-I/opt/local/include'
:debug:configure CXX='/usr/bin/clang++'
:debug:configure CXXFLAGS='-pipe -Os -stdlib=libc++ -arch x86_64'
:debug:configure F77='/opt/local/bin/gfortran-mp-8'
:debug:configure F77FLAGS='-m64'
:debug:configure F90FLAGS='-pipe -Os -m64'
:debug:configure FCFLAGS='-pipe -Os -m64'
:debug:configure FFLAGS='-pipe -Os'
:debug:configure INSTALL='/usr/bin/install -c'
:debug:configure LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
:debug:configure LIBRARY_PATH='/opt/local/lib'
:debug:configure MACOSX_DEPLOYMENT_TARGET='10.12'
:debug:configure OBJC='/usr/bin/clang'
:debug:configure OBJCFLAGS='-pipe -Os -arch x86_64'
:debug:configure OBJCXX='/usr/bin/clang++'
:debug:configure OBJCXXFLAGS='-pipe -Os -stdlib=libc++ -arch x86_64'
for this particular port, I need to override the build and pass F77 as the linker. I tried
build.args-append CC=${configure.cc} \
F77=${configure.f77}
build.target lib/${os.platform}${os.major}/libtaucs.a
build {
ui_info "Building libtaucs archives:"
system -W ${worksrcpath} "${build.cmd} ${build.args} ${build.target}"
}
with 'LD = $(F77)’ in the Makefile, but that didn’t work. How should I pass this during build?

I suppose that ought to work, except that perhaps the problem you're running into is that ${build.args} is a list of values. If you want to concatenate all those list items with spaces and include that expanded value in a string, as you're doing here, you'll need to use the expand operator ({*}). Technically, build.cmd and build.target (and all other MacPorts options) are lists too, though they might only contain one item at the moment. To properly expand all those lists into strings, you'd use: "{*}${build.cmd} {*}${build.args} {*}${build.target}".

However, you probably should not override the build phase with this custom code block, because then you don't get a lot of conveniences that MacPorts provides. The custom build block you showed above doesn't look like it's trying to do anything different from the standard build phase, so I would just remove it. If you let MacPorts do the build phase the default way, you wouldn't run into that problem. Though I'm not 100% certain that was the problem, since you didn't show the way in which it didn't work.

[Mark Brethen]

LD is currently defined as $(CC). There is a bsd port that is maintained and current, see #57669 <https://trac.macports.org/ticket/57669>. They patch the makefile, using f77 instead, among other changes. My patch is as follows:

diff -ur taucs.orig/config/darwin.mk taucs/config/darwin.mk
--- taucs.orig/config/darwin.mk 2003-08-24 05:10:51.000000000 -0500
+++ taucs/config/darwin.mk 2018-11-24 20:16:59.000000000 -0600
@@ -9,32 +9,32 @@
DEFFLG=-D

#CC = gcc
-CFLAGS = -O3 -faltivec
+CFLAGS += $(PICFLAG)
COUTFLG = -o ./

-FC = $(CC)
-FFLAGS = $(CFLAGS)
+FC = $(F77)
+FFLAGS += $(PICFLAG)
FOUTFLG = $(COUTFLG)

-LD = $(CC)
-LDFLAGS = $(CFLAGS)
+LD = $(FC)
+LDFLAGS := -L$(DIRLIB) -L./ $(CFLAGS)
LOUTFLG = $(COUTFLG)

-AR = ar -cr
-AOUTFLG =
+AR += cr
+#AOUTFLG =

-RANLIB = ranlib
+#RANLIB = ranlib
RM = rm -rf

-LIBBLAS = -framework vecLib
-LIBLAPACK =
-LIBMETIS = -Lexternal/lib/darwin -lmetis
+LIBBLAS = -framework Accelerate
+LIBLAPACK = -framework Accelerate
+LIBMETIS = -lmetis

-LIBF77 = -Lexternal/lib/darwin -lf2c
+#LIBF77 = -Lexternal/lib/darwin -lf2c
# crypto is for ftime, which is used by the timing routines
# the documentation says its in libcompat, but on my system
# there is no libcompat, but libcrypto provides it
-LIBC = -lm -lcrypto
+#LIBC = -lm -lcrypto


I think their build process requires overriding the build phase in macports.


Mark Brethen

Did you check that "LD" is actually the variable that this Makefile uses to set the linker? There's no need to do this two-step approach anyway. You can just put LD=$[configure.f77} in the build.args.
David

(resent with correction)
I’m using the compilers group with
compilers.choose cc f77
compilers.setup require_fortran
:debug:configure CC='/usr/bin/clang'
:debug:configure CC_PRINT_OPTIONS='YES'
:debug:configure CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_marbre_ports_math_taucs/taucs/work/.CC_PRINT_OPTIONS'
:debug:configure CFLAGS='-pipe -Os -arch x86_64'
:debug:configure CPATH='/opt/local/include'
:debug:configure CPPFLAGS='-I/opt/local/include'
:debug:configure CXX='/usr/bin/clang++'
:debug:configure CXXFLAGS='-pipe -Os -stdlib=libc++ -arch x86_64'
:debug:configure F77='/opt/local/bin/gfortran-mp-8'
:debug:configure F77FLAGS='-m64'
:debug:configure F90FLAGS='-pipe -Os -m64'
:debug:configure FCFLAGS='-pipe -Os -m64'
:debug:configure FFLAGS='-pipe -Os'
:debug:configure INSTALL='/usr/bin/install -c'
:debug:configure LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
:debug:configure LIBRARY_PATH='/opt/local/lib'
:debug:configure MACOSX_DEPLOYMENT_TARGET='10.12'
:debug:configure OBJC='/usr/bin/clang'
:debug:configure OBJCFLAGS='-pipe -Os -arch x86_64'
:debug:configure OBJCXX='/usr/bin/clang++'
:debug:configure OBJCXXFLAGS='-pipe -Os -stdlib=libc++ -arch x86_64'
for this particular port, I need to override the build and pass F77 as the linker. I tried
build.args-append CC=${configure.cc} \
F77=${configure.f77}
build.target lib/${os.platform}${os.major}/libtaucs.a
build {
ui_info "Building libtaucs archives:"
system -W ${worksrcpath} "${build.cmd} ${build.args} ${build.target}"
}
with 'LD = $(F77)’ in the Makefile, but that didn’t work. How should I pass this during build?

I suppose that ought to work, except that perhaps the problem you're running into is that ${build.args} is a list of values. If you want to concatenate all those list items with spaces and include that expanded value in a string, as you're doing here, you'll need to use the expand operator ({*}). Technically, build.cmd and build.target (and all other MacPorts options) are lists too, though they might only contain one item at the moment. To properly expand all those lists into strings, you'd use: "{*}${build.cmd} {*}${build.args} {*}${build.target}".
However, you probably should not override the build phase with this custom code block, because then you don't get a lot of conveniences that MacPorts provides. The custom build block you showed above doesn't look like it's trying to do anything different from the standard build phase, so I would just remove it. If you let MacPorts do the build phase the default way, you wouldn't run into that problem. Though I'm not 100% certain that was the problem, since you didn't show the way in which it didn't work.

[Ryan Schmidt]

Post by Mark Brethen
I think their build process requires overriding the build phase in macports.

Why do you think that?

Their build process has no idea how their build process is being invoked. It should make no difference to their build process whether a command is called by the standard MacPorts build phase or by you manually running a command with system. But allowing MacPorts to use the standard build phase is almost always what you want to do, so that you can benefit from all of the conveniences that it offers.

[Mark Brethen]

This is how the bsd port builds taucs:



50 post-configure:
51 @${CP} -r ${WRKSRC} ${WRKSRC}_SHARED
52
53 archives: configure
54 @${PRINTF} "\n\n%s\n\n\n" "Building libtaucs archives:"
55 (cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
56 ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} lib/FreeBSD/libtaucs.a)
57 (cd ${WRKSRC}_SHARED && ${SETENV} ${MAKE_ENV} PICFLAG="${PICFLAG}" \
58 ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} lib/FreeBSD/libtaucs.a)
59
60 lib: archives
61 @${PRINTF} "\n\n%s\n\n\n" "Building shared library:"
62 (cd ${WRKSRC}_SHARED/lib/FreeBSD && \
63 ${FC} ${CFLAGS} ${PICFLAG} ${LDFLAGS} -shared \
64 -o libtaucs.so.1 -Wl,-x -Wl,-soname,libtaucs.so.1 \
65 -Wl,--whole-archive libtaucs.a -Wl,--no-whole-archive)
66 ${STRIP_CMD} ${WRKSRC}_SHARED/lib/FreeBSD/libtaucs.so.1
67
68 bins: lib
69 @${PRINTF} "\n\n%s\n\n\n" "Building (dynamically-linked) executables:"
70 #for the second pass through WRKSRC_SHARED, use a nonexistent MAKEOBJDIR to
71 #prevent make from entering the obj subdirectories and breaking the build (see,
72 #for example, the description of .OBJDIR in make(1)):
73 (cd ${WRKSRC}_SHARED && \
74 ${SETENV} ${MAKE_ENV} MAKEOBJDIR="${NONEXISTENT}" \
75 ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} ${BINS:S|^|bin/FreeBSD/|})
76
77 do-build: bins

lib:archives builds the dynamic library, $(PICFLAG) is defined as


.if ${ARCH} == "sparc64"
39 PICFLAG?= -fPIC
40 .else
41 PICFLAG?= -fpic
42 .endif


bins:lib builds the executables defined as

BINS?= direct iter taucs_run

I don’t know how to do all this with macports default build.


Mark Brethen

Post by Ryan Schmidt

Post by Mark Brethen
I think their build process requires overriding the build phase in macports.

Why do you think that?
Their build process has no idea how their build process is being invoked. It should make no difference to their build process whether a command is called by the standard MacPorts build phase or by you manually running a command with system. But allowing MacPorts to use the standard build phase is almost always what you want to do, so that you can benefit from all of the conveniences that it offers.

[Ryan Schmidt]

Post by Mark Brethen

Post by Ryan Schmidt

Post by Mark Brethen
I think their build process requires overriding the build phase in macports.

Why do you think that?
Their build process has no idea how their build process is being invoked. It should make no difference to their build process whether a command is called by the standard MacPorts build phase or by you manually running a command with system. But allowing MacPorts to use the standard build phase is almost always what you want to do, so that you can benefit from all of the conveniences that it offers.

52
53 archives: configure
55 (cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
56 ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} lib/FreeBSD/libtaucs.a)
57 (cd ${WRKSRC}_SHARED && ${SETENV} ${MAKE_ENV} PICFLAG="${PICFLAG}" \
58 ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} lib/FreeBSD/libtaucs.a)
59
60 lib: archives
62 (cd ${WRKSRC}_SHARED/lib/FreeBSD && \
63 ${FC} ${CFLAGS} ${PICFLAG} ${LDFLAGS} -shared \
64 -o libtaucs.so.1 -Wl,-x -Wl,-soname,libtaucs.so.1 \
65 -Wl,--whole-archive libtaucs.a -Wl,--no-whole-archive)
66 ${STRIP_CMD} ${WRKSRC}_SHARED/lib/FreeBSD/libtaucs.so.1
67
68 bins: lib
70 #for the second pass through WRKSRC_SHARED, use a nonexistent MAKEOBJDIR to
71 #prevent make from entering the obj subdirectories and breaking the build (see,
73 (cd ${WRKSRC}_SHARED && \
74 ${SETENV} ${MAKE_ENV} MAKEOBJDIR="${NONEXISTENT}" \
75 ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} ${BINS:S|^|bin/FreeBSD/|})
76
77 do-build: bins
lib:archives builds the dynamic library, $(PICFLAG) is defined as
.if ${ARCH} == "sparc64"
39 PICFLAG?= -fPIC
40 .else
41 PICFLAG?= -fpic
42 .endif
bins:lib builds the executables defined as
BINS?= direct iter taucs_run

Yes, I saw that the FreeBSD port does this. I am not familiar with FreeBSD ports, except that I've noticed that their ports are defined as Makefiles, likely with the full range of Makefile syntax at their disposal. MacPorts ports on the other hand are defined using a Portfile written in the Tcl language, with most of the Tcl syntax available. MacPorts conveniences should make writing custom Tcl code unnecessary in most cases, but for complex ports or poor build systems sometimes more of the work has to be done in Tcl code. Or you may be able to patch the project's existing Makefile to do what you want. Or you can of course write a custom Makefile, stash it in the files directory, and have the Portfile drive that, if that's easier; several ports do that already (see my lp_solve port for example).

Post by Mark Brethen
I don’t know how to do all this with macports default build.

My point was just that the custom build phase you showed us earlier seemed to be doing the same thing as the standard build phase, except offering fewer of the MacPorts conveniences. (It did not use ${build.env}, for example.) As such, it wasn't useful. If you need to do more than that, then overriding the build phase might indeed be needed. But consider whether allowing MacPorts to do the normal build phase, and then running additional parts of the build afterward in a post-build block, might make more sense.

I'm not certain that following a FreeBSD ports recipe to the letter is necessarily appropriate for MacPorts. For example, I see here that they make a copy of the configured source directory so that they can build libtaucs.a "normally" in the first directory and then with position-independent code in the second directory so that a shared library can be created from it. As far as I know, compilers produce position-independent code by default on macOS, so building the static library twice would not be necessary for us.

You asked in a separate thread how to create a macOS dynamic library from a static library (likely because you were trying to emulate what FreeBSD was doing here). I'd never considered trying that before. I'd probably focus instead on modifying the original Makefile to produce a macOS dylib directly from the existing object files, the way other projects' build systems do.

[Mark Brethen]

Post by Ryan Schmidt
For example, I see here that they make a copy of the configured source directory so that they can build libtaucs.a "normally" in the first directory and then with position-independent code in the second directory so that a shared library can be created from it.

You are referring to the $(PICFLAG) variable in the second build? I wondered about that, and had read that it wasn’t necessary for Mac OSX?

[Ryan Schmidt]

Post by Mark Brethen

Post by Ryan Schmidt
For example, I see here that they make a copy of the configured source directory so that they can build libtaucs.a "normally" in the first directory and then with position-independent code in the second directory so that a shared library can be created from it.

You are referring to the $(PICFLAG) variable in the second build?

Yes.

Post by Mark Brethen
I wondered about that, and had read that it wasn’t necessary for Mac OSX?

Yes. PIC is on by default on macOS.

[Mark Brethen]

Attached is my current portfile which builds both a static archive and dynamic library.

[Ryan Schmidt]

Mark,

I still think it would be easier to patch the build system to build the dynamic library and link the programs with it, rather than trying to call individual makefile targets from the portfile.

After looking at the build system for awhile, I see now why this project's build system is so difficult to modify: they don't use autotools or anything similar that would provide normal configure script or a template Makefile.in that you can easily patch. Instead, they provide a C program configurator/taucs_config.c that gets compiled and run which creates the makefile.

But I was able to patch the configurator so that it generates a macOS dynamic library and use it instead of the static library. I've attached my files, based on yours, to the ticket: https://trac.macports.org/ticket/57669

I had intended that the static library would still get built, but it looks like the configurator has decided that since nothing depends on the static library anymore, it should not get built at all. As far as I'm concerned, that's fine; we prefer dynamic libraries anyway.

I made some more changes:

Added "dist_subdir ${name}/${version}" because the distfile is unversioned.

Used "master_sites ${homepage}${version}" to reduce code duplication and because the server automatically redirects http traffic to https.

Used "depends_lib-append port:metis" so that a libmetis.dylib located outside the MacPorts prefix does not satisfy the dependency.

Used "-dynamiclib" instead of "-shared" when building the dynamic library.

Used "universal_variant no" since you're not passing -arch flags to the build, so a universal build doesn't work.

Fixed FFLAGS and CC.

Passed OSTYPE=darwin to the build so that we don't have to copy darwin.mk to another name.

Re-added -faltivec on PowerPC, since the patching of darwin.mk removed it; haven't tested if this actually works on PowerPC or if it maybe still needs vecLib.

Added a destroot phase.

Probably other changes I've forgotten.

It installs for me, and runs, to the extent that the programs can print their help messages; I didn't know how to test them further.

\r

Post by Mark Brethen
Attached is my current portfile which builds both a static archive and dynamic library.
<Portfile><patch-taucs-build.diff>
#for the second pass through WRKSRC_SHARED, use a nonexistent MAKEOBJDIR to
71 #prevent make from entering the obj subdirectories and breaking the build (see,
73 (cd ${WRKSRC}_SHARED && \
74 ${SETENV} ${MAKE_ENV} MAKEOBJDIR="${NONEXISTENT}" \
75 ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} ${BINS:S|^|bin/FreeBSD/|})
which corresponds to
$(DIREXE)direct$(EXEEXT): $(STDDEPS) $(DIROBJ)direct$(OBJEXT) $(DIRLIB)libtaucs$(LIBEXT)
$(LD) $(LDFLAGS) \
$(LOUTFLG)$(DIREXE)direct$(EXEEXT) \
$(DIROBJ)direct$(OBJEXT) \
-L$(DIRLIB) -ltaucs \
$(LIBS)
$(DIREXE)taucs_run$(EXEEXT): $(STDDEPS) $(DIROBJ)taucs_run$(OBJEXT) $(DIRLIB)libtaucs$(LIBEXT)
$(LD) $(LDFLAGS) \
$(LOUTFLG)$(DIREXE)taucs_run$(EXEEXT) \
$(DIROBJ)taucs_run$(OBJEXT) \
-L$(DIRLIB) -ltaucs \
$(LIBS)
$(DIREXE)iter$(EXEEXT): $(STDDEPS) $(DIROBJ)iter$(OBJEXT) $(DIRLIB)libtaucs$(LIBEXT)
$(LD) $(LDFLAGS) \
$(LOUTFLG)$(DIREXE)iter$(EXEEXT) \
$(DIROBJ)iter$(OBJEXT) \
-L$(DIRLIB) -ltaucs \
$(LIBS)
in the makefile. They set a nonexistent directory using OBJDIR with BSD make. Gnu make does not have this option, does it? It seems rediculus to have to build the library each time. Can I issue these with ‘system', omitting the library object?
Mark Brethen

Post by Ryan Schmidt

Post by Mark Brethen

Post by Ryan Schmidt
For example, I see here that they make a copy of the configured source directory so that they can build libtaucs.a "normally" in the first directory and then with position-independent code in the second directory so that a shared library can be created from it.

You are referring to the $(PICFLAG) variable in the second build?

Yes.

Post by Mark Brethen
I wondered about that, and had read that it wasn’t necessary for Mac OSX?

Yes. PIC is on by default on macOS.

[Mark Brethen]

A couple of remaining thoughts I had:

1. The BSD port uses metis4 whereas macports metis distro is at v5. I didn’t check to see which one it used. If it builds alright, I assume it will work.

2. Calculix-ccx requires taucs at build. Should it matter if the static library exists, or not?

Thanks!

Post by Ryan Schmidt
Mark,
I still think it would be easier to patch the build system to build the dynamic library and link the programs with it, rather than trying to call individual makefile targets from the portfile.
After looking at the build system for awhile, I see now why this project's build system is so difficult to modify: they don't use autotools or anything similar that would provide normal configure script or a template Makefile.in that you can easily patch. Instead, they provide a C program configurator/taucs_config.c that gets compiled and run which creates the makefile.
But I was able to patch the configurator so that it generates a macOS dynamic library and use it instead of the static library. I've attached my files, based on yours, to the ticket: https://trac.macports.org/ticket/57669
I had intended that the static library would still get built, but it looks like the configurator has decided that since nothing depends on the static library anymore, it should not get built at all. As far as I'm concerned, that's fine; we prefer dynamic libraries anyway.
Added "dist_subdir ${name}/${version}" because the distfile is unversioned.
Used "master_sites ${homepage}${version}" to reduce code duplication and because the server automatically redirects http traffic to https.
Used "depends_lib-append port:metis" so that a libmetis.dylib located outside the MacPorts prefix does not satisfy the dependency.
Used "-dynamiclib" instead of "-shared" when building the dynamic library.
Used "universal_variant no" since you're not passing -arch flags to the build, so a universal build doesn't work.
Fixed FFLAGS and CC.
Passed OSTYPE=darwin to the build so that we don't have to copy darwin.mk to another name.
Re-added -faltivec on PowerPC, since the patching of darwin.mk removed it; haven't tested if this actually works on PowerPC or if it maybe still needs vecLib.
Added a destroot phase.
Probably other changes I've forgotten.
It installs for me, and runs, to the extent that the programs can print their help messages; I didn't know how to test them further.
\r

Post by Mark Brethen
Attached is my current portfile which builds both a static archive and dynamic library.
<Portfile><patch-taucs-build.diff>
#for the second pass through WRKSRC_SHARED, use a nonexistent MAKEOBJDIR to
71 #prevent make from entering the obj subdirectories and breaking the build (see,
73 (cd ${WRKSRC}_SHARED && \
74 ${SETENV} ${MAKE_ENV} MAKEOBJDIR="${NONEXISTENT}" \
75 ${MAKE} ${_MAKE_JOBS} ${MAKE_ARGS} ${BINS:S|^|bin/FreeBSD/|})
which corresponds to
$(DIREXE)direct$(EXEEXT): $(STDDEPS) $(DIROBJ)direct$(OBJEXT) $(DIRLIB)libtaucs$(LIBEXT)
$(LD) $(LDFLAGS) \
$(LOUTFLG)$(DIREXE)direct$(EXEEXT) \
$(DIROBJ)direct$(OBJEXT) \
-L$(DIRLIB) -ltaucs \
$(LIBS)
$(DIREXE)taucs_run$(EXEEXT): $(STDDEPS) $(DIROBJ)taucs_run$(OBJEXT) $(DIRLIB)libtaucs$(LIBEXT)
$(LD) $(LDFLAGS) \
$(LOUTFLG)$(DIREXE)taucs_run$(EXEEXT) \
$(DIROBJ)taucs_run$(OBJEXT) \
-L$(DIRLIB) -ltaucs \
$(LIBS)
$(DIREXE)iter$(EXEEXT): $(STDDEPS) $(DIROBJ)iter$(OBJEXT) $(DIRLIB)libtaucs$(LIBEXT)
$(LD) $(LDFLAGS) \
$(LOUTFLG)$(DIREXE)iter$(EXEEXT) \
$(DIROBJ)iter$(OBJEXT) \
-L$(DIRLIB) -ltaucs \
$(LIBS)
in the makefile. They set a nonexistent directory using OBJDIR with BSD make. Gnu make does not have this option, does it? It seems rediculus to have to build the library each time. Can I issue these with ‘system', omitting the library object?
Mark Brethen

Post by Ryan Schmidt

Post by Mark Brethen

Post by Ryan Schmidt
For example, I see here that they make a copy of the configured source directory so that they can build libtaucs.a "normally" in the first directory and then with position-independent code in the second directory so that a shared library can be created from it.

You are referring to the $(PICFLAG) variable in the second build?

Yes.

Post by Mark Brethen
I wondered about that, and had read that it wasn’t necessary for Mac OSX?

Yes. PIC is on by default on macOS.

[Ryan Schmidt]

Post by Mark Brethen
1. The BSD port uses metis4 whereas macports metis distro is at v5. I didn’t check to see which one it used.

taucs builds with "-lmetis", in other words, libmetis.dylib, whatever version that may be.

Post by Mark Brethen
If it builds alright, I assume it will work.

One would hope so, but that's not necessarily true.

Post by Mark Brethen
2. Calculix-ccx requires taucs at build. Should it matter if the static library exists, or not?

It depends on how the build system has been written. If it links with "-L/opt/local/lib -ltaucs", then it will find the libtaucs.dylib symlink* which points to the libtaucs.1.dylib dynamic library and it will hopefully work. If on the other hand it links with "/opt/local/lib/libtaucs.a" then it will fail because that file isn't there; probably in that case the build system should be fixed to link with the dynamic library.


* I realized I forgot to include that symlink in the Portfile; I've updated the Portfile in the ticket with this.

[Mark Brethen]

It failed to build for me:

:info:build ld: library not found for -lf2c
:info:build collect2: error: ld returned 1 exit status

:info:build 1 error generated.
:info:build make: *** [obj/darwin/direct.o] Error 1
:info:build make: *** Waiting for unfinished jobs....
:info:build make: Leaving directory `/opt/local/var/macports/build/_Users_marbre_ports_math_taucs/taucs/work/taucs'
:info:build Command failed: cd "/opt/local/var/macports/build/_Users_marbre_ports_math_taucs/taucs/work/taucs" && /usr/bin/make -j4 -w all PREFIX=/opt/local
:info:build Exit code: 2
:error:build Failed to build taucs: command execution failed
:debug:build Error code: CHILDSTATUS 19021 2


f2c should be added as a dependency.


Mark Brethen

Post by Ryan Schmidt

Post by Mark Brethen
1. The BSD port uses metis4 whereas macports metis distro is at v5. I didn’t check to see which one it used.

taucs builds with "-lmetis", in other words, libmetis.dylib, whatever version that may be.

Post by Mark Brethen
If it builds alright, I assume it will work.

One would hope so, but that's not necessarily true.

Post by Mark Brethen
2. Calculix-ccx requires taucs at build. Should it matter if the static library exists, or not?

It depends on how the build system has been written. If it links with "-L/opt/local/lib -ltaucs", then it will find the libtaucs.dylib symlink* which points to the libtaucs.1.dylib dynamic library and it will hopefully work. If on the other hand it links with "/opt/local/lib/libtaucs.a" then it will fail because that file isn't there; probably in that case the build system should be fixed to link with the dynamic library.
* I realized I forgot to include that symlink in the Portfile; I've updated the Portfile in the ticket with this.

[Joshua Root]

Post by Ryan Schmidt

Post by Mark Brethen
build {
ui_info "Building libtaucs archives:"
system -W ${worksrcpath} "${build.cmd} ${build.args} ${build.target}"
}
with 'LD = $(F77)’ in the Makefile, but that didn’t work. How should I pass this during build?

I suppose that ought to work, except that perhaps the problem you're running into is that ${build.args} is a list of values. If you want to concatenate all those list items with spaces and include that expanded value in a string, as you're doing here, you'll need to use the expand operator ({*}). Technically, build.cmd and build.target (and all other MacPorts options) are lists too, though they might only contain one item at the moment. To properly expand all those lists into strings, you'd use: "{*}${build.cmd} {*}${build.args} {*}${build.target}".

The function of {*} is to pass a list to a command as multiple
arguments, one per list element. That is not what's desired here, as the
command to be run by system should be given in a single argument.

Perhaps you were thinking of 'join'? But that shouldn't really be needed
here either.

- Josh

[Mark Brethen]

I used placeholders in the makefile then passed the environment variables using reinplace statements. That worked, however I’m getting a make: lib/darwin16/libtaucs.a: Permission denied. Sounds like I need to change the permissions after extracting the source. Is there a tar flag for that?

[Mark Brethen]

Another oddity I noticed in the log is

:info:build ld: warning: directory not found for option '-L/opt/local/var/macports/build/_Users_marbre_ports_math_taucs/taucs/work/taucs/lib/darwin16/'

That’s a valid path!

Mark Brethen

I used placeholders in the makefile then passed the environment variables using reinplace statements. That worked, however I’m getting a make: lib/darwin16/libtaucs.a: Permission denied. Sounds like I need to change the permissions after extracting the source. Is there a tar flag for that?
<main.log>
Mark Brethen

Post by Joshua Root

Post by Ryan Schmidt

Post by Mark Brethen
build {
ui_info "Building libtaucs archives:"
system -W ${worksrcpath} "${build.cmd} ${build.args} ${build.target}"
}
with 'LD = $(F77)’ in the Makefile, but that didn’t work. How should I pass this during build?

I suppose that ought to work, except that perhaps the problem you're running into is that ${build.args} is a list of values. If you want to concatenate all those list items with spaces and include that expanded value in a string, as you're doing here, you'll need to use the expand operator ({*}). Technically, build.cmd and build.target (and all other MacPorts options) are lists too, though they might only contain one item at the moment. To properly expand all those lists into strings, you'd use: "{*}${build.cmd} {*}${build.args} {*}${build.target}".

The function of {*} is to pass a list to a command as multiple
arguments, one per list element. That is not what's desired here, as the
command to be run by system should be given in a single argument.
Perhaps you were thinking of 'join'? But that shouldn't really be needed
here either.
- Josh

[Ryan Schmidt]

Post by Mark Brethen
Another oddity I noticed in the log is
:info:build ld: warning: directory not found for option '-L/opt/local/var/macports/build/_Users_marbre_ports_math_taucs/taucs/work/taucs/lib/darwin16/'
That’s a valid path!

Hmm, not sure why you would see that error if that directory does exist.

However I didn't see that line in the main.log you sent.

What I did see was:

ld: warning: directory not found for option '-L-L./'

[Ryan Schmidt]

I used placeholders in the makefile then passed the environment variables using reinplace statements. That worked, however I’m getting a make: lib/darwin16/libtaucs.a: Permission denied. Sounds like I need to change the permissions after extracting the source. Is there a tar flag for that?

No that's not the reason. What the log actually says is:

:info:build lib/darwin16/libtaucs.a
:info:build make: lib/darwin16/libtaucs.a: Permission denied
:info:build make: *** [lib/darwin16/libtaucs.a] Error 1

In other words, it's trying to execute lib/darwin16/libtaucs.a as if it were a program. It's a library, not a program, and because of that, it doesn't have the execute bit, and because of that, you get the message that permission is denied. But the real problem to fix is: why is it trying to run a library as if it were a program?

I also see from the log that the C compiler is being invoked as "cc" instead of the value of of ${configure.cc}.

[Mark Brethen]

It was operator error : D When patching config/$(OSTYPE).mk, I had undefined $(RANLIB) in the makefile below:

include config/$(OSTYPE).mk

$(DIRLIB)libtaucs$(LIBEXT): $(libtaucs_content) $(STDDEPS)
- $(RM) $(DIRLIB)libtaucs$(LIBEXT)
$(AR) $(AOUTFLG)$(DIRLIB)libtaucs$(LIBEXT) $(libtaucs_content)
$(RANLIB) $(DIRLIB)libtaucs$(LIBEXT)

Mark Brethen

Post by Ryan Schmidt

I used placeholders in the makefile then passed the environment variables using reinplace statements. That worked, however I’m getting a make: lib/darwin16/libtaucs.a: Permission denied. Sounds like I need to change the permissions after extracting the source. Is there a tar flag for that?

:info:build lib/darwin16/libtaucs.a
:info:build make: lib/darwin16/libtaucs.a: Permission denied
:info:build make: *** [lib/darwin16/libtaucs.a] Error 1
In other words, it's trying to execute lib/darwin16/libtaucs.a as if it were a program. It's a library, not a program, and because of that, it doesn't have the execute bit, and because of that, you get the message that permission is denied. But the real problem to fix is: why is it trying to run a library as if it were a program?
I also see from the log that the C compiler is being invoked as "cc" instead of the value of of ${configure.cc}.

[Ryan Schmidt]

Post by Joshua Root

Post by Ryan Schmidt

with 'LD = $(F77)’ in the Makefile, but that didn’t work. How should I pass this during build?

I suppose that ought to work, except that perhaps the problem you're running into is that ${build.args} is a list of values. If you want to concatenate all those list items with spaces and include that expanded value in a string, as you're doing here, you'll need to use the expand operator ({*}). Technically, build.cmd and build.target (and all other MacPorts options) are lists too, though they might only contain one item at the moment. To properly expand all those lists into strings, you'd use: "{*}${build.cmd} {*}${build.args} {*}${build.target}".

The function of {*} is to pass a list to a command as multiple
arguments, one per list element. That is not what's desired here, as the
command to be run by system should be given in a single argument.
Perhaps you were thinking of 'join'? But that shouldn't really be needed
here either.

Perhaps I was. Ok, never mind then, I was just taking a wild stab at something that might be wrong, given that the custom build phase seemed unnecessary and therefore wrong, and since we weren't told in what way it "didn't work".