libxmi @1.2: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]

[pelopor-pelopor (pelopor)]

Build process stops at the "configure" stage.

:info:configure checking whether the C compiler (/usr/bin/clang -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch arm64 -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk -arch arm64) works... no
:info:configure configure: error: installation or configuration problem: C compiler cannot create executables.
:info:configure Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_libxmi/libxmi/work/libxmi-1.2" && ./configure --prefix=/opt/local --infodir=/opt/local/share/info
:info:configure Exit code: 1

To build libxmi requires to use "autoreconf" rather than patches.

[pelopor-pelopor (pelopor)]

use autoreconf

[ryandesign (Ryan Carsten Schmidt)]

Why? What error did you get? Please attach the main.log file from the failed build attempt.

[pelopor-pelopor (pelopor)]

Just "configure" failed

[ryandesign (Ryan Carsten Schmidt)]

When configure fails, there is usually more information in configure's log, as mentioned in the main.log:

:error:configure Failed to configure libxmi: consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_libxmi/libxmi/work/libxmi-1.2/config.log

Could you attach the config.log file as well?

[pelopor-pelopor (pelopor)]

OK, I attached config.log.

[ryandesign (Ryan Carsten Schmidt)]

The error in the config.log is:

configure:1070:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
 1070 | main(){return(0);}
      | ^
      | int
1 error generated.

This could be patched, like we do in many other ports, instead of using autoreconf. Does using autoreconf offer other advantages, beyond fixing this problem? Usually we try to avoid it unless patching is prohibitively difficult.

[rwwh (Rob Hooft)]

I have several tools in my regular "macports installation" list that depend on libxmi, like "hugin-app". If this is not going to be fixed generally, how do I use "autoreconf" in practice to solve this?

[ryandesign (Ryan Carsten Schmidt)]

Rob, if you want to receive replies to ticket comments you have to Cc yourself, which I've now done for you.

Replying to rwwh:

If this is not going to be fixed generally,

It's not that it is not going to be fixed; it's that nobody has fixed it yet. We contribute to MacPorts in our spare time.

how do I use "autoreconf" in practice to solve this?

The reporter provided a patch​ which you ​can apply. However, if you use this, remove the line that increases the revision to 2; fixing this bug does not warrant increasing the revision.

[rwwh (Rob Hooft)]

Thanks Ryan, I understand everyone is doing this in the spare time.... I just was not able to execute on the report here without these more step-wise instructions.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

This could be patched, like we do in many other ports, instead of using autoreconf. Does using autoreconf offer other advantages, beyond fixing this problem? Usually we try to avoid it unless patching is prohibitively difficult.

I gave it a try and this configure script is so old that there are quite a few things that need to be patched. autoreconfing is indeed much easier.