libgcrypt-config with +universal

[Ryan Schmidt]

On May 8, 2015, at 3:21 AM, René J.V. Bertin wrote:

> On Thursday May 07 2015 21:20:30 Ryan Schmidt wrote:
> 
>>> port:libgcrypt uses muniversal, so I'm guessing it ought to be only a question of copying the right libgcrypt-config to the combined destroot, no?
>> 
>> That's not how muniversal works. It merges the files produced for each arch. Looks like someone already noticed that the merge would fail because of this difference in host, and has chosen in the case of a universal build to replace it with "${os.arch}" (of the build machine) which would be either "i386" or "powerpc".
>> If we want it to print a value based on the machine on which it's currently running then we would have to modify the code of libgcrypt-config to do that.
> 
> Misunderstanding: what I had in mind was to "replace it with [a version of] ${os.arch} (of the build machine) which would be either [x86_64 or] i386 or".
> Which, incidentally, is "to modify the code of libgcrypt-config" in my book ;)

If libgcrypt is installed universal, what would you suggest "libgcrypt --host" should say? gwenhywfar4 is comparing its value against the --host with which gwenhywfar4 is being configured. MacPorts doesn't supply that argument to configure, so it's being computed anyway.

I note gwenhywfar4 has the same complaint about libgpg-error. libgpg-error doesn't use the muniversal portgroup and the port does no special patching to its config program. On my system, libgpg-error's host was "x86_64-apple-darwin14.3.0" but gwenhywfar4 has now detected the host as "x86_64-apple-darwin14.4.0", so it looks like even a change in the patch version number of OS X will cause this mismatch message, which is just not useful.

>> I imagine the developer of libgcrypt will tell you of course host is used, else they wouldn't have provided an option in libgcrypt-config to find it. I'm sure it is used when cross compiling or on systems other than OS X.
> 
> If libgcrypt works by loading parts (of itself) dynamically at runtime, it would be reasonable to print the kind of warning I saw when a mismatch is detected at build time.

A mismatch of the host parameter does not necessarily indicate that there is a mismatch of the library or binary architecture.

> The best approach would probably be to teach the libgcrypt build system of universal binaries, and come up with an appropriate solution. That's something we can leave to the port maintainer and the libgcypt developers, IMHO.

I would be inclined to remove the portion of the gwenhywfar4 that detects for this condition and prints these messages, because I don't believe they are applicable to us on OS X when we're not cross-compiling. Or do nothing and just ignore the message.