-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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 |
Actually my guess based on the error is that Run If you are building with
|
If you do have
|
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/ |
Thank you for the tips. In general, I use macports rather than brew.
However, I do have
Getting this from autogen:
I am attaching the Many thanks! |
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 |
I have progressed a little. By defining environment variable
Now make is failing. :)
|
Try deleting the |
That helped, and the process moved on. Thank you! Now the error that I get from make is:
|
Remove the You'll need to re-run autoconf: make distclean
ACLOCAL_PATH=/opt/local/share/aclocal ./autogen.sh
ACLOCAL_PATH=/opt/local/share/aclocal ./configure |
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 |
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. |
Thanks! Looks like this version of ld does not have
I have moved further, and now getting this error:
I wonder what I am missing this time. :) Thanks for helping! |
Try this (though it should have been autodetected): make clean
LDFLAGS=-lgmodule-2.0 ./configure
make |
Unfortunately this throws a different error just after calling .configure:
|
I think gmodule-2.0 is missing... |
Try this: echo 'main(){}' > t.c
gcc -lgmodule-2.0 -o /dev/null t.c also try this with 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. |
The above failed with the library not found. However, I have located it. Macports installs its libs in /opt/local/lib, see:
The test you suggested passes if gcc is invoked as follows:
However, I cannot figure out how to pass the libdir option to make/automake etc. I have tried and failed with both of these:
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. :) |
I think you want this: LDFLAGS=-L/opt/local/lib ./configure From
|
That worked. make, install and desktop-install all worked now. When I launch it, however, I now get:
|
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: |
I use XQuartz a good bit but it usually launches automatically. I’ll have a look. |
Interesting, maybe get an It would be nice to make xnec2c automatically launch Quartz. Let me know if you know what is involved there. |
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!
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!
I just pushed a commit to detect OSX and address the 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 |
Hi @RafalLukawiecki, were you able to test the updated patches to build on OSX using the procedure above (remember to |
Occasionally I get ssh access to a macOS machine using homebrow installed in
The fix is to add 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. |
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 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? |
Thanks for figuring out the 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 |
@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 intltool-update --pot
make update-po -Eric |
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. |
If there is a compelling reason to use libtool then thats fine, otherwise lets strip it out of the build process and simplify.
Yep. See at least this discussion linked by line number (you might find the rest of the file informative as well):
I have seriously considered it, most notably because (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.) |
I tried to reproduce the build problem with macOS (13.1) and macports (MacPorts-2.8.0.tar.bz2) installed (without privileged access) to I made sure no homebrew stuff was in any env variable ( I installed (at least) these ports: autoconf automake glib2-devel gtk3 pkgconfig I tried both the current xnec2c master branch (commit 007671d) with In all cases, I ran the following sequence of commands to build after using
And for my buildsystem cleanup branch:
Everything built successfully. I even tried replacing the So, about the four issues mentioned above:
So I guess I am done here. |
@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. |
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
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
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
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
I think this is complete, so closing. Please re-open if the issue persists. |
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
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
FYI, autogen has generated this output:
The text was updated successfully, but these errors were encountered: