kerberos5 does not build on PPC Tiger, Mac OS X 10.4.11, because void value cannot be ignored as it ought to be

[ballapete (Peter "Pete" Dyballa)]

/usr/bin/gcc-4.0 -DHAVE_CONFIG_H -DGET_TGT_VIA_PASSWD -DPRINC_LOOK_AHEAD -DCMD_PATH='"/bin /local/bin"' -I../../include -I../../include  -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE -I/opt/local/include -pipe -Os -arch ppc -fno-common -Wall -Wcast-align -Wshadow -Wmissing-prototypes -Wno-format-zero-length -Wmissing-format-attribute -Wmissing-prototypes -Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas -Wsign-compare -Wnewline-eof -Wdeclaration-after-statement -Werror-implicit-function-declaration  -c main.c
main.c: In function ‘get_configured_defccname’:
main.c:818: error: void value not ignored as it ought to be
make[2]: *** [main.o] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_net_kerberos5/kerberos5/work/krb5-1.13-final/src/clients/ksu'

[ballapete (Peter "Pete" Dyballa)]

main.log

[ballapete (Peter "Pete" Dyballa)]

I think I have found the cause for the failure – it's not easy to understand what GCC 4.2 reports! On (PPC) Tiger unsetenv() is a void, but the return value of unsetenv() is compared with zero, which has to fail. Changing that block

-    if (unsetenv(KRB5_ENV_CCNAME) != 0) {
-        retval = errno;
-        com_err(prog_name, retval, _("while clearing the value of %s"),
-                KRB5_ENV_CCNAME);
-        return retval;
-    }

to simple

+    /* On PPC Tiger unsetenv is a void(), nothing to compare. */
+    unsetenv(KRB5_ENV_CCNAME);

seems to be equivalent and to fix the issue. This is a rather crude fix, because I have no idea which #defines for the Darwin/Mac OS X version exist.

[ballapete (Peter "Pete" Dyballa)]

Proposed patch for (PPC) Tiger/Mac OS X 10.4.11

[geoffd2]

Same failure here with gcc-4.0 (which I think is what you are using, not apple-gcc42). (Different bug with 4.2 see ​https://trac.macports.org/ticket/47006) I'll try your patch.

[ballapete (Peter "Pete" Dyballa)]

Replying to geoffdown@…:

Same failure here with gcc-4.0 (which I think is what you are using, not apple-gcc42).

Yes, you are correct!

I'll try your patch.

Did it work for you?

[geoffd2]

Replying to Peter_Dyballa@…:

Replying to geoffdown@…:

Same failure here with gcc-4.0 (which I think is what you are using, not apple-gcc42).

Yes, you are correct!

I'll try your patch.

Did it work for you?

Yes - but I see the new version @1.13.2_0 has the same problem. Are the maintainers not listening?

[geoffd2]

The patch works for the new version as well - at least as far as allowing installation to complete. Whether there is any functional downside I am unqualified to judge.

[ballapete (Peter "Pete" Dyballa)]

Replying to geoffdown@…:

The patch works for the new version as well - at least as far as allowing installation to complete. Whether there is any functional downside I am unqualified to judge.

The original six lines try to check whether the invocation of unsetenv(KRB5_ENV_CCNAME) returns an error, and if so that the error happened while clearing the environment variable KRB5_ENV_CCNAME. Since on Tiger unsetenv() is a void function, i.e. it does not return a return value, it's not possible to check success this simple way. A real substitute of the original six lines would try to read the environment after clearing and report then that clearing failed.

[ryandesign (Ryan Carsten Schmidt)]

Replying to geoffdown@…:

Are the maintainers not listening?

I only just became the maintainer 3 days ago in r136339. Prior to that, the port has not had a maintainer since Yves gave it up in 2007 in r21217.

I'm trying to assess what to do with all the open tickets. If you believe the patch provided here is correct, please file a ticket with the developers of kerberos5 and provide the patch to them so they can include it in the next version, and please note here the URL of the ticket.

[ryandesign (Ryan Carsten Schmidt)]

The ​R project fixed a similar problem in their software back in 2007 with this patch:

Index: src/main/sysutils.c
===================================================================
--- src/main/sysutils.c	(revision 40400)
+++ src/main/sysutils.c	(revision 40401)
@@ -26,6 +26,10 @@
 #include <config.h>
 #endif
 
+#if defined(__APPLE__) && ( ! defined(_POSIX_C_SOURCE) || (_POSIX_C_SOURCE < 200112L) )
+#define _POSIX_C_SOURCE 200112L /* for correct unsetenv */
+#endif
+
 #include <stdlib.h> /* for putenv */
 #include <Defn.h>
 #include <R_ext/Riconv.h>

That's part of revision r40401 in their repository at ​https://svn.r-project.org/R/. See ​https://stat.ethz.ch/pipermail/r-devel/2007-January/044228.html. Perhaps something similar would help kerberos5.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #48845.

[miniupnp (Thomas BERNARD)]

patch to check if unsetenv() succeded using getenv()

[miniupnp (Thomas BERNARD)]

Replying to Peter_Dyballa@…:

Replying to geoffdown@…:

The patch works for the new version as well - at least as far as allowing installation to complete. Whether there is any functional downside I am unqualified to judge.

The original six lines try to check whether the invocation of unsetenv(KRB5_ENV_CCNAME) returns an error, and if so that the error happened while clearing the environment variable KRB5_ENV_CCNAME. Since on Tiger unsetenv() is a void function, i.e. it does not return a return value, it's not possible to check success this simple way. A real substitute of the original six lines would try to read the environment after clearing and report then that clearing failed.

It is what I've done with my patch : unsetenv() then check with getenv()

[miniupnp (Thomas BERNARD)]

From the linux man page : Prior to glibc 2.2.2, unsetenv() was prototyped as returning void; more recent glibc versions follow the POSIX.1-2001-compliant prototype shown in the SYNOPSIS.

[miniupnp (Thomas BERNARD)]

it has been fixed upstream : ​https://github.com/krb5/krb5/commit/7eee546db10e907666e02fdded4f512e8d0faf4c

[ballapete (Peter "Pete" Dyballa)]

Replying to thomas@…:

it has been fixed upstream : ​https://github.com/krb5/krb5/commit/7eee546db10e907666e02fdded4f512e8d0faf4c

kerberos5 @1.13.2_2 still uses krb5-1.13.2-final.tar.gz and needs that patch.

It seems, last updated on Thursday evening UTC, yesterday, does not provide any of the two patches for Tiger. Thomas' patch needs a patch: the paths to the files may not start with "src/". This path element needs to be removed. With this corrected patch kerberos5 @1.13.2_2 builds fine on PPC Tiger, Mac OS X 10.4.11.

[rickyzhang82 (Ricky Zhang)]

Hi Gentelmen above,

I experienced compile issue for kerberos5 in Tiger. But with different errors.

It set 0.0 to dynamic library major and minor version. gcc isn't happy with this. gcc has no documents whatsoever to describe their gazillion number of parameter. I got stuck to compile this dependency for installing git.

Any new update?

[ballapete (Peter "Pete" Dyballa)]

Kerberos5 is now @1.20.1, installed, and working. So this ticket can be closed IMO.

[kencu (Ken)]

Thanks!