mpack: fix configure and build failures

[frankdean]

Description

configure was failing as its tests appear to be pre C99 requiring implicit int.

Makefile.am failed to build due to a local variable being null.

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 15.3.1 24D70 arm64
Xcode 16.2 16C5032a

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• checked your Portfile with port lint?
• tried a full install with sudo port -vs install?
• tested basic functionality of all binary files?

[ryandesign]

There is an open ticket for this problem. The commit message should conclude with the lines

Closes: https://trac.macports.org/ticket/71604

so that Trac will auto-close the ticket when the PR is merged.

[ryandesign]

As explained in the guide, don't increase the revision just to fix a build failure since nothing has changed for anyone (i.e. those with older less-picky compilers) who was already able to install the port (unless using autoreconf causes more changes for this software than I'm used to).

Suggested change

	revision 2
	revision 1

[ryandesign]

It's a good idea to add a comment to explain why we are autoreconfing. That way it's easier to determine in future updates of the port whether it can be removed.

Suggested change

	use_autoreconf yes
	# Regenerate configure to fix implicit int errors.
	# Also we are patching Makefile.am.
	use_autoreconf yes

[ryandesign]

${prefix}/share/man is the default value for mandir in recent versions of autotools. Now that you're autoreconfing, there's no need to specify this.

Suggested change

	configure.args --mandir=${prefix}/share/man

[ryandesign]

What was the error message you got before making this change? Are we sure this is the best fix?

[frankdean]

Because the LIB_SOCKET wasn't being set at all, even to a null string, the value was being passed on the CLI causing a build failure...

clang: error: no such file or directory: '@LIB_SOCKET@'

The variable should have been set by a local m4 macro. The macro wasn't actually being called, but when it is called, it causes more issues as it sets incorrect values for LIBS on systems which already have the functions implemented in the standard library. I've implemented a more theoretically complete fix although the end result is the same but tidier.