Ohana's mktemp shadows BSD's mktemp, leading to 'man' failure

[jester@…]

After psconfig ipp-2.5 etc., Ohana's mktemp is the first mktemp that's found on the path.

On our Linux installation (Suse 10), man needs nroff needs OpenBSD's /bin/mktemp, but finds Ohana's mktemp instead, and of course can't do anything with it:

mktemp: error while loading shared libraries: libdvo.so: cannot open shared object file: No such file or directory
/usr/bin/nroff: Can't create temp directory, exiting...

Suggested fix: rename Ohana's mktemp into ohana_mktemp or something like that.

[giebink]

Ohana's mktemp is still being written but it does not seem to interfere with man, possibly because Suse 10 is no longer in use.

[eugene]

two comments on this:

1) I suspect the error is still present in Suse, so we should keep it around so we know about this issue. IPP operations has never used Suse, but we'd like to know if there are issues that affect installations (they could be more general problems).

2) I think the error is actually mis-interpretted. it is not that nroff is unable to use mktemp (the ohana version has the same API as /bin/mktemp), but that the invocation in nroff is not supplying the LD_LIBRARY_PATH needed. Not sure why PATH is propagated and LD_LIBRARY_PATH is not. Still, the suggested would work. It might also be better for the Ohana build system to only generate mktemp if it is not found on the local system (the ohana version was meant as a replacement since not all systems provide mktemp).