Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configure fails on macOS #16

Closed
RafalLukawiecki opened this issue Nov 16, 2022 · 35 comments
Closed

configure fails on macOS #16

RafalLukawiecki opened this issue Nov 16, 2022 · 35 comments

Comments

@RafalLukawiecki
Copy link

I am trying to build on the current version of macOS. I think I have gtk3-devel and related packages in place, as I use them for other projects. When I run .configure I get this error output. Any suggestions? I had a look in the script but it is not obvious to me.

Many thanks,
Rafal EI6LA

checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether configure should try to set CFLAGS... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking whether make sets $(MAKE)... (cached) yes
./configure: line 4595: syntax error near unexpected token `PACKAGE,'
./configure: line 4595: `PKG_CHECK_MODULES(PACKAGE, $pkg_modules)'

FYI, autogen has generated this output:

Preparing the xnec2c build system...please wait

Found GNU Autoconf version 2.71
Found GNU Automake version 1.16.5

Warning:  libtoolize does not appear to be available.  This means that
the automatic build preparation via autoreconf will probably not work.
Preparing the build by running each step individually, however, should
work and will be done automatically for you if autoreconf fails.

Fortunately, glibtoolize was found which means that your system may simply
have a non-standard or incomplete GNU Autotools install.  If you have
sufficient system access, it may be possible to quell this warning by
running:

   sudo ln -s /opt/local/bin/glibtoolize /opt/local/bin/libtoolize

Found GNU Libtool version 2.4.7

Automatically preparing build ... done

The xnec2c build system is now prepared.  To build here, run:
  ./configure
  make
@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 16, 2022

Interesting, it would be great to make it build on OSX! Thanks for writing.

I think its missing some autoconf macros. Can you send me the ./configure file that it created so I can see what is missing?

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 16, 2022

Actually my guess based on the error is that pkg-config is missing.

Run pkg-config on the command line. Does it give an error?

If you are building with brew then this might work:

brew install pkg-config

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 16, 2022

If you do have pkg-config installed and it still doesn't build,then what version are you running?

]$ pkg-config --version
0.27.1

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 16, 2022

This article is a bit old, but it could shed light on the problem since the error looks about the same: https://tgebarowski.github.io/2008/08/31/problem-with-pkg_check_modules-under-mac-os-x/

@RafalLukawiecki
Copy link
Author

Thank you for the tips. In general, I use macports rather than brew. pkg-config is 0.29.2 and it has been here for quite some time. I think the script fails because the autotools PKG_CHECK_MODULES fails in this line of the configure:

PKG_CHECK_MODULES(PACKAGE, $pkg_modules)

However, I do have glibtoolize and I have tried this, as suggested by autogen:

sudo ln -s /opt/local/bin/glibtoolize /opt/local/bin/libtoolize

Getting this from autogen:

Preparing the xnec2c build system...please wait

Found GNU Autoconf version 2.71
Found GNU Automake version 1.16.5
Found GNU Libtool version 2.4.7

Automatically preparing build ... done

The xnec2c build system is now prepared.  To build here, run:
  ./configure
  make

I am attaching the configure for you to have a look at. Line 4595 fails. Added extension .txt to make it GH-friendly.

Many thanks!
73 Rafal EI6LA

configure.txt

@RafalLukawiecki
Copy link
Author

I had a look at the article and it matches my situation. aclocal, autoheader etc are all in /usr/local/bin. However, the path to .m4 files is /opt/local/share/aclocal. The article suggests using -I option with aclocal. However, I do not know which script of config file to modify to add that path. I could not find an invocation of aclocal.

@RafalLukawiecki
Copy link
Author

I have progressed a little. By defining environment variable ACLOCAL_PATH I was able to rerun autoconf and configure successfully. I used:

ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh 
ACLOCAL_PATH=/opt/local/share/aclocal ./configure 

Now make is failing. :)

$ ACLOCAL_PATH=/opt/local/share/aclocal make
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in src
gcc -DHAVE_CONFIG_H -I. -I..  -DPROGRAMNAME_LOCALEDIR=\""/usr/local/share/locale"\" -DPACKAGE_DATA_DIR=\"""\" -DPACKAGE_LOCALE_DIR=\""/usr/local//locale"\" -I/opt/local/include/gtk-3.0 -I/opt/local/include/at-spi2-atk/2.0 -I/opt/local/include/at-spi-2.0 -I/opt/local/include -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include -I/opt/local/include -I/opt/local/include/gtk-3.0 -I/opt/local/include/gio-unix-2.0 -I/opt/local/include -I/opt/local/include/cairo -I/opt/local/include -I/opt/local/include/pango-1.0 -I/opt/local/include/harfbuzz -I/opt/local/include/pango-1.0 -I/opt/local/include/fribidi -I/opt/local/include -I/opt/local/include/harfbuzz -I/opt/local/include -I/opt/local/include/atk-1.0 -I/opt/local/include/cairo -I/opt/local/include/pixman-1 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/libpng16 -I/opt/local/include -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include  --pedantic -Wall -std=gnu11 -O2 -g -Wformat -Werror=format-security -fpie -Wno-overlength-strings -DGTK_DISABLE_SINGLE_INCLUDES -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGSEAL_ENABLE -DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-honor-nans -fno-signed-zeros -fno-math-errno -MT mathlib.o -MD -MP -MF .deps/mathlib.Tpo -c -o mathlib.o mathlib.c
mathlib.c:22:10: fatal error: 'link.h' file not found
#include <link.h>
         ^~~~~~~~
1 error generated.
make[2]: *** [mathlib.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 17, 2022

Try deleting the #include <link.h> line because I don't think its used any more and should have been cleaned up.

@RafalLukawiecki
Copy link
Author

That helped, and the process moved on. Thank you! Now the error that I get from make is:

gcc --pedantic -Wall -std=gnu11 -O2 -g -Wformat -Werror=format-security -fpie -Wno-overlength-strings -DGTK_DISABLE_SINGLE_INCLUDES -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGSEAL_ENABLE -DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-honor-nans -fno-signed-zeros -fno-math-errno -Wl,--export-dynamic -Wl,--as-needed  -o xnec2c main.o mathlib.o measurements.o interface.o callbacks.o console.o callback_func.o calculations.o cmnd_edit.o geom_edit.o gnuplot.o draw.o draw_structure.o draw_radiation.o fields.o fork.o geometry.o ground.o xnec2c.o input.o matrix.o utils.o nec2_model.o network.o optimize.o plot_freqdata.o radiation.o rc_config.o shared.o somnec.o xnec2c-resources.o -L/opt/local/lib -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl  -lpthread -lm
ld: unknown option: --export-dynamic
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [xnec2c] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 17, 2022

Remove the -Wl,--export-dynamic option on line 2 of src/Makefile.am and see if it builds.

You'll need to re-run autoconf:

make distclean
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh 
ACLOCAL_PATH=/opt/local/share/aclocal ./configure 

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 17, 2022

Like this:

diff --git a/src/Makefile.am b/src/Makefile.am
index cb58906..a85c366 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,5 +1,5 @@
 ## Process this file with automake to produce Makefile.in
-AM_LDFLAGS = -Wl,--export-dynamic -Wl,--as-needed
+AM_LDFLAGS = -Wl,--as-needed
 
 # Disable warnings for overlength-strings, nothing we can do about that for GTK resources.
 # Maybe some compilers can't handle the length, but gcc and clang take it fine.
diff --git a/src/mathlib.c b/src/mathlib.c
index 49dbd86..46afef5 100644

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 17, 2022

Please also try a single dash instead of a double-dash like the patch below because GTK might really need export-dynamic to work:

diff --git a/src/Makefile.am b/src/Makefile.am
index cb58906..cad6bba 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,5 +1,5 @@
 ## Process this file with automake to produce Makefile.in
-AM_LDFLAGS = -Wl,--export-dynamic -Wl,--as-needed
+AM_LDFLAGS = -Wl,-export-dynamic -Wl,--as-needed
 
 # Disable warnings for overlength-strings, nothing we can do about that for GTK resources.
 # Maybe some compilers can't handle the length, but gcc and clang take it fine.

@RafalLukawiecki
Copy link
Author

Thanks! Looks like this version of ld does not have --as-needed at all, and the spelling of the other one uses an underscore, ie. -export_dynamic. Having changed that line to:

AM_LDFLAGS = -Wl,-export_dynamic

I have moved further, and now getting this error:

gcc --pedantic -Wall -std=gnu11 -O2 -g -Wformat -Werror=format-security -fpie -Wno-overlength-strings -DGTK_DISABLE_SINGLE_INCLUDES -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGSEAL_ENABLE -DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-honor-nans -fno-signed-zeros -fno-math-errno -Wl,-export_dynamic  -o xnec2c main.o mathlib.o measurements.o interface.o callbacks.o console.o callback_func.o calculations.o cmnd_edit.o geom_edit.o gnuplot.o draw.o draw_structure.o draw_radiation.o fields.o fork.o geometry.o ground.o xnec2c.o input.o matrix.o utils.o nec2_model.o network.o optimize.o plot_freqdata.o radiation.o rc_config.o shared.o somnec.o xnec2c-resources.o -L/opt/local/lib -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl  -lpthread -lm
Undefined symbols for architecture x86_64:
  "_g_module_supported", referenced from:
      _Gtk_Builder in interface.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [xnec2c] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I wonder what I am missing this time. :) Thanks for helping!

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 17, 2022

Try this (though it should have been autodetected):

make clean
LDFLAGS=-lgmodule-2.0 ./configure
make

@RafalLukawiecki
Copy link
Author

Unfortunately this throws a different error just after calling .configure:

checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether configure should try to set CFLAGS... yes
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Users/rafal/Projects/xnec2c':
configure: error: C compiler cannot create executables
See `config.log' for more details

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 18, 2022

I think gmodule-2.0 is missing...

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 18, 2022

Try this:

echo 'main(){}' > t.c
gcc -lgmodule-2.0 -o /dev/null t.c

also try this with -2.0

echo 'main(){}' > t.c
gcc -lgmodule -o /dev/null t.c

If it succeeds without error, then you have gmodule. If it gives an error, then you'll need to find the gmodule-2.0 (or equivalent) for macports.

@RafalLukawiecki
Copy link
Author

The above failed with the library not found. However, I have located it. Macports installs its libs in /opt/local/lib, see:

$ l /opt/local/lib/*gm*
-rwxr-xr-x  1 root  wheel    52K 17 Sep 01:04 /opt/local/lib/libgmodule-2.0.0.dylib
-rw-r--r--  1 root  wheel    35K 17 Sep 01:02 /opt/local/lib/libgmodule-2.0.a
lrwxr-xr-x  1 root  wheel    22B 17 Sep 01:04 /opt/local/lib/libgmodule-2.0.dylib -> libgmodule-2.0.0.dylib
-rwxr-xr-x  1 root  wheel   533K  5 Apr  2022 /opt/local/lib/libgmp.10.dylib
-rw-r--r--  1 root  wheel   916K  5 Apr  2022 /opt/local/lib/libgmp.a
lrwxr-xr-x  1 root  wheel    15B  5 Apr  2022 /opt/local/lib/libgmp.dylib -> libgmp.10.dylib
-rwxr-xr-x  1 root  wheel    45K  5 Apr  2022 /opt/local/lib/libgmpxx.4.dylib
-rw-r--r--  1 root  wheel    33K  5 Apr  2022 /opt/local/lib/libgmpxx.a
lrwxr-xr-x  1 root  wheel    16B  5 Apr  2022 /opt/local/lib/libgmpxx.dylib -> libgmpxx.4.dylib
lrwxr-xr-x  1 root  admin    22B 17 Nov 11:59 /opt/local/lib/libpgm.dylib -> libnetpbm.11.100.dylib

The test you suggested passes if gcc is invoked as follows:

$ gcc -L/opt/local/lib -lgmodule-2.0 -o /dev/null t.c
t.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main(){}
^
1 warning generated.

However, I cannot figure out how to pass the libdir option to make/automake etc. I have tried and failed with both of these:

LD_LIBRARY_PATH=/opt/local/lib make
ACLOCAL_PATH=/opt/local/share/aclocal ./configure --libdir=/opt/local/lib 

I am afraid I am not familiar with gtk nor its devel and automake framework. If you have any suggestions how to pass the necessary paths to the makefile, I will be glad to try. Thank you for helping—it seems we are moving, slowly, but ahead. :)

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 18, 2022

I think you want this:

LDFLAGS=-L/opt/local/lib ./configure

From ./configure --help:

Some influential environment variables:
  CC          C compiler command
  CFLAGS      C compiler flags
  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
              nonstandard directory <lib dir>
  LIBS        libraries to pass to the linker, e.g. -l<library>
  CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
              you have headers in a nonstandard directory <include dir>
  PKG_CONFIG  path to pkg-config utility
  PKG_CONFIG_PATH
              directories to add to pkg-config's search path
  PKG_CONFIG_LIBDIR
              path overriding pkg-config's built-in search path
  PACKAGE_CFLAGS
              C compiler flags for PACKAGE, overriding pkg-config
  PACKAGE_LIBS
              linker flags for PACKAGE, overriding pkg-config
  CPP         C preprocessor

Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.


@RafalLukawiecki
Copy link
Author

That worked. make, install and desktop-install all worked now. When I launch it, however, I now get:

$ xnec2c
(xnec2c:58784): Gtk-WARNING **: 20:33:53.852: cannot open display: :0

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 18, 2022

This error means it can't find the X server.

xnec2c is an XWindows program so you'll need to run it under X Windows. I'm not familiar with OSX, I've never even run a X program there.

But a quick google search reveals a few articles that might help:

@RafalLukawiecki
Copy link
Author

I use XQuartz a good bit but it usually launches automatically. I’ll have a look.

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 18, 2022

Interesting, maybe get an xterm in quartz and then run xnec2c? Not sure.

It would be nice to make xnec2c automatically launch Quartz. Let me know if you know what is involved there.

KJ7LNW pushed a commit that referenced this issue Nov 18, 2022
The OSX version of `ld` expects `-Wl,--export_dynamic` not
`-Wl,--export-dynamic`.

This helps address bug #16: #16

At least, it helps address the issue.  To build on Mac OS X with
macports you may need the following:

and finally, xnec2c is an X app so be sure to run it under XQuartz.
KJ7LNW pushed a commit that referenced this issue Nov 18, 2022
The OSX version of `ld` expects `-Wl,--export_dynamic` not
`-Wl,--export-dynamic`.

This helps address bug #16: #16

At least, it helps address the issue.  To build on Mac OS X with
macports you may need the following:

and finally, xnec2c is an X app so be sure to run it under XQuartz.

Big thanks to Rafal Lukawiecki EI6LA for helping troubleshoot to get
xnec2c building on OSX!
KJ7LNW pushed a commit that referenced this issue Nov 18, 2022
The OSX version of `ld` expects `-Wl,--export_dynamic` not
`-Wl,--export-dynamic`.

This helps address bug #16: #16

At least, it helps address the issue.  To build on Mac OS X with
macports you may need the following:

and finally, xnec2c is an X app so be sure to run it under XQuartz.

Big thanks to Rafal Lukawiecki EI6LA for helping troubleshoot to get
xnec2c building on OSX!
@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 18, 2022

I just pushed a commit to detect OSX and address the -export_dynamic issues. Can you git pull and see if it builds?

You will still need to specify custom paths, but this should compile cleanly on OSX if it works:

make distclean
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh 
LDFLAGS=-L/opt/local/lib ./configure
make
./src/xnec2c

@KJ7LNW
Copy link
Owner

KJ7LNW commented Nov 22, 2022

Hi @RafalLukawiecki, were you able to test the updated patches to build on OSX using the procedure above (remember to git pull first)?

@ndim
Copy link
Contributor

ndim commented Dec 1, 2022

Occasionally I get ssh access to a macOS machine using homebrow installed in $HOME, and I have just managed to reproduce the _g_module_supported "symbol not found" problem from above:

Undefined symbols for architecture arm64:
  "_g_module_supported", referenced from:
      _Gtk_Builder in interface.o
ld: symbol(s) not found for architecture arm64

The fix is to add PKG_CHECK_CONFIG([GMODULE], [gmodule-2.0]) in configure.ac and adding $(GMODULE_CFLAGS) and $(GMODULE_LDADD) in appropriate places in src/Makefile.am, replacing the AC_CHECK_LIB([gmodule-2.0], [g_module_open]) in configure.ac.

This might be a bug in something else missing the dependency on gmodule, but whatever, if this is the workaround, I can live with that.

I have not looked into macports at all yet.

@ndim
Copy link
Contributor

ndim commented Dec 1, 2022

Oh and by the way, all the libtool related stuff in autogen.sh is misleading, as xnec2c does not use libtool AT ALL. Switching to libtool might be helpful with some aspects, but maybe not with some others. xnec2c IS using system specific calls to load plugin library functions at runtime. It might also be possible to use libtool's libltdl library, but I am not sure of the advantages and the drawbacks of that for xnec2c, as I do not know xnec2c well enough to judge.

And regarding gettextize etc. - while xnec2c has the infrastructure partly in place for translations, there are no translation, so it does not really matter if the translation stuff actually works or not, it just needs to build.

@KJ7LNW Why is the translation stuff there? Because you want translations in the future? Or just because they have always been there?

@KJ7LNW
Copy link
Owner

KJ7LNW commented Dec 1, 2022

@ndim,

Thanks for figuring out the _g_module_supported issue for homebrew! Assuming that fix works on normal Linux builds then please apply your patch.

Here is a brew formula that I've started from a fresh brew install to get the dependencies figured out. It seems to work but note this SE issue that I haven't sorted out yet.. Comments and suggestions are welcome:

class Xnec2c < Formula
  desc "Multi-threaded EM tool based on NEC2 to model antenna radiation patterns"
  homepage "https://www.xnec2c.org/"
  url "https://www.xnec2c.org/releases/xnec2c-v4.4.12.tar.gz"
  sha256 "e98af1e8b9098df9cc03f90950358b846cc6a2965e79c0114ab711fbe51272c5"
  license "GPL-3.0-or-later"

  depends_on "atk"
  depends_on "cairo"
  depends_on "gdk-pixbuf"
  depends_on "glib"
  depends_on "gtk+3"
  depends_on "librsvg"
  depends_on "pango"
  depends_on "autoconf"
  depends_on "automake"

  def install
    system "./autogen.sh"
    system "./configure", *std_configure_args
    system "make"
    system "make install"
    system "make desktop-install"
  end

  test do
    system "#{bin}/xnec2c", "-h"
  end
end

@KJ7LNW
Copy link
Owner

KJ7LNW commented Dec 1, 2022

@ndim, regarding the translation stuff:

Its there because its always been there. I asked Neoklis the same thing some time ago and he said he set it up but never got around to it.

However:

I have started fixing up translations and it is 80% done... but the branch isn't in a clean state to be pushed. Please leave translation stuff as-is to avoid any merge issues in the po/ tree for when it is ready. I'm hoping to have that out in early 2023.

I'm not sure how things like gettextize interact with intltoolize but I'm pretty sure we'll be switching to intltoolize and related commands. At the moment this is the process that seems to work:

intltool-update --pot
make update-po

-Eric

@ndim
Copy link
Contributor

ndim commented Dec 1, 2022

homebrew formula noted. Might look into the formula at some later time.

Regarding gettextize and intltoolize: I have been involved with libgphoto2's build system for about the last 20 years, so I am kind of familiar with the gettextize based buildsystem aspects. I could get that to work properly easily by basically mostly copying what libgphoto2 does, perhaps minus some special things I did for libgphoto2 specifically. intltoolize I will need to learn, but that might be interesting to learn about.

@KJ7LNW
Copy link
Owner

KJ7LNW commented Dec 1, 2022

@ndim, please see #20 to continue the translation discussion so this issue can remain macOS focused.

@KJ7LNW
Copy link
Owner

KJ7LNW commented Dec 1, 2022

@ndim,

Oh and by the way, all the libtool related stuff in autogen.sh is misleading, as xnec2c does not use libtool AT ALL. Switching to libtool might be helpful with some aspects, but maybe not with some others.

If there is a compelling reason to use libtool then thats fine, otherwise lets strip it out of the build process and simplify.

xnec2c IS using system specific calls to load plugin library functions at runtime.

Yep. See at least this discussion linked by line number (you might find the rest of the file informative as well):

It might also be possible to use libtool's libltdl library, but I am not sure of the advantages and the drawbacks of that for xnec2c, as I do not know xnec2c well enough to judge.

I have seriously considered it, most notably because libltdl supports win32 but dlopen does not. The change for libtldl is probably pretty trivial but I've not looked into it. Open a new issue or PR if you want to tackle that; all of the changes would happen in this single file: src/mathlib.c

(There is a certain irony about bringing this up win32 in this macOS issue, but see #21 for more if you're curious about the Windows build.)

@ndim
Copy link
Contributor

ndim commented Dec 2, 2022

I tried to reproduce the build problem with macOS (13.1) and macports (MacPorts-2.8.0.tar.bz2) installed (without privileged access) to $HOME/macports.

I made sure no homebrew stuff was in any env variable (printenv|grep brew empty), and set PATH, MANPATH, PKG_CONFIG_PATH to point to the macports directories.

I installed (at least) these ports: autoconf automake glib2-devel gtk3 pkgconfig

I tried both the current xnec2c master branch (commit 007671d) with gmodule-2.0 added to pkg_modules, and one of my buildsystem cleanup branches.

In all cases, I ran the following sequence of commands to build after using git clean to purge all files not in the git repo:

autoreconf -vis .
./configure --prefix=$PWD/_i
make
make install

And for my buildsystem cleanup branch:

make distcheck

Everything built successfully.

I even tried replacing the autoreconf call with autogen.sh. No change.

So, about the four issues mentioned above:

  • The AM_LDFLAGS issue has already been fixed in master.

  • The gmodule stuff has been identified and fixed (maybe not in master yet)

  • I cannot reproduce the issue of the missing pkg.m4 file

  • As to how to automatically start the macOS X11 software, that is not a build issue, so I probably cannot help. I only have occasional ssh access to a Mac, I have never sat in front of one.

So I guess I am done here.

@KJ7LNW
Copy link
Owner

KJ7LNW commented Dec 2, 2022

@ndim, you rock! Awesome, well done.

Commit and push with the existing buildsystem PR and we'll roll it in when the PR is ready.

ndim added a commit to ndim/xnec2c that referenced this issue Dec 2, 2022
Look for gmodule-2.0 via PKG_CHECK_MODULES.

This removes the need for the AC_CHECK_LIB() check later.

Not sure why we need to explicitly link against gmodule-2.0
on macOS and not on Linux, but this certainly builds on both.

Fixes one of four from KJ7LNW#16
ndim added a commit to ndim/xnec2c that referenced this issue Dec 4, 2022
Look for gmodule-2.0 via PKG_CHECK_MODULES.

This removes the need for the AC_CHECK_LIB() check later.

Not sure why we need to explicitly link against gmodule-2.0
on macOS and not on Linux, but this certainly builds on both.

Fixes one of four from KJ7LNW#16
ndim added a commit to ndim/xnec2c that referenced this issue Dec 5, 2022
Look for gmodule-2.0 via PKG_CHECK_MODULES.

This removes the need for the AC_CHECK_LIB() check later.

Not sure why we need to explicitly link against gmodule-2.0
on macOS and not on Linux, but this certainly builds on both.

Fixes one of four from KJ7LNW#16
KJ7LNW pushed a commit that referenced this issue May 10, 2023
Look for gmodule-2.0 via PKG_CHECK_MODULES.

This removes the need for the AC_CHECK_LIB() check later.

Not sure why we need to explicitly link against gmodule-2.0
on macOS and not on Linux, but this certainly builds on both.

Fixes one of four from #16
@KJ7LNW
Copy link
Owner

KJ7LNW commented Mar 31, 2024

I think this is complete, so closing. Please re-open if the issue persists.

@KJ7LNW KJ7LNW closed this as completed Mar 31, 2024
KJ7LNW pushed a commit that referenced this issue Aug 14, 2024
Look for gmodule-2.0 via PKG_CHECK_MODULES.

This removes the need for the AC_CHECK_LIB() check later.

Not sure why we need to explicitly link against gmodule-2.0
on macOS and not on Linux, but this certainly builds on both.

Fixes one of four from #16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants