Build instructions for macOS fail about lib3270

[andrebreves]

The initial problem in autogen.sh is that libtoolize needs to be glibtoolize to use the Homebrew-installed version.

To help others with the same problem, this can be resolved by linking libtoolize to glibtoolize

ln -s /usr/local/bin/glibtoolize /usr/local/bin/libtoolize

Once that is fixed, the build fails in the autoconf stage with configure: error: libssl not present.

I fixed the open-keg script to detect correctly if a formulae is keg-only, it seems that the json output for brew info had changed. It's working now and autogen.sh finishes without errors.

But now there seems to be a change to the all target of Makefile to depend on a all-macos target.

$ make all
make: *** No rule to make target `all-macos', needed by `all'.  Stop.

[PerryWerneck]

Probably a collateral effect of the library updates. I cant test it because I dont have an available MacOS to test Will try to install a VM for testing.

[PerryWerneck]

It was a collateral effect of the win32 specifics. I'll wrote the all-macos to be the same of all-linux. I think this will fix it.

[andrebreves]

I was able to start the build process with make all-linux, but then stopped after some source code problems.

I updated the source code in my fork and was able to finish the compilation process, but was unable to install (maybe due to the same problem):

$ make install
make[1]: Nothing to be done for `install'.
# Install library
# Install default configs
make: *** No rule to make target `install-macos-dev', needed by `install-dev'.  Stop.

@andrebreves As far I understood you used the Linux build isn't? What do you think about copy all sources from Linux network module to Mac and reapply your changes to útil.c?

[PerryWerneck]

I created a new branch macos and did some adjustments in the configure.ac and Makefile based on my jhbuild notes. I hope that 'make all' will now work.

I was able to start the build process with make all-linux, but then stopped after some source code problems.
I updated the source code in my fork and was able to finish the compilation process, but was unable to install (maybe due to the same problem):

[curtosis]

I'm not sure if it should be part of the same issue, but after the fix to autogen.sh, the build now fails on M1 Macs because somewhere it's looking for the gettext headers (libintl.h). My autotools-fu isn't good enough to find precisely where, but it appears to be hardcoding /usr/local/include as opposed to the brew include directory. This fails on M1 because homebrew installs in /opt/local on that platform (/usr/local/ is for x86 binaries, which can often run under Rosetta2).

(Note that this isn't specifically an M1 support problem — it would likely also fail on any other homebrew install to a non-standard location.)

[PerryWerneck]

The path for libintl should be detected by configure; it's not hardcoded, but, opt it's a really strange path for includes and I'm not sure if autotools search this path (it's searching for the header using the standard macro AC_CHECK_HEADER). It fails on configure or build? Did you tried to manually set the path using CFLAGS?

[curtosis]

Setting LDFLAGS and CFLAGS get past the configure errors, but now the actual build fails. Two main errors I've identified so far:

• src/core/util.c needs to include <stdlib.h> (for malloc/free declarations)
• src/core/macos/connect.c seems to be out of sync with src/include/internals.h; the SOCK_CLOSE macro is pointing to a nonexistent member sock of the connection struct.

[PerryWerneck]

Hi,

Are you using the branch 'macos'? I did a lot of fixes for mac builds this week only on this branch and it's building fine with jhbuild. They'll be on master after a full test in all platforms/distros.

By the way: Same situation on libv3270 and pw3270.

Setting LDFLAGS and CFLAGS get past the configure errors, but now the actual build fails. Two main errors I've identified so far:

• src/core/util.c needs to include <stdlib.h> (for malloc/free declarations)
• src/core/macos/connect.c seems to be out of sync with src/include/internals.h; the SOCK_CLOSE macro is pointing to a nonexistent member sock of the connection struct.

[curtosis]

Ah! No, I hadn't switched over to those branches.

It took a while to sort out jhbuild -- meta-gtk-osx-gtk3 won't build for me, and I had to manually jhbuild openssl -- but I at least got to the point where the build fails because it's trying to link with the x86_64 version of libiconv. That's of course, an M1-specific problem.

I may wait for things to stabilize a bit more, though I'm happy to test things out.

[PerryWerneck]

Well, if it's trying to link is because it's finding it. I think you have the x86_64 available and 'set' somewhere in your environment. I had a similar problem in the past when trying to cross compile to windows on linux and took me some time to find the right 'configure' settings to avoid this.

I think the macos version of lib3270 and libv3270 are stable now. Yesterday I was able to build the entire pw3270 application with jhbuild without erros and did a really small testing and it seens to be running. Will have to check some macos details more related to the UI (like the desktop shortcut action) and the bundle creation.

It took a while to sort out jhbuild -- meta-gtk-osx-gtk3 won't build for me, and I had to manually jhbuild openssl -- but I at least got to the point where the build fails because it's trying to link with the x86_64 version of libiconv. That's of course, an M1-specific problem.
I may wait for things to stabilize a bit more, though I'm happy to test things out.