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.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
