icu @55.1 — add a +norename variant

[mcglk (Ken McGlothlen)]

From the icu ​readme.html file:

"Disable renaming: By default, ICU library entry point names have an ICU version suffix. Turn this off for a system-level installation, to enable upgrading ICU without breaking applications."

This turned out to be important for one of our applications that wasn't handling this gracefully, and because MacPorts is often used in a way that could be described as "system-level," it seemed like adding a new default variant was the right answer.

The diff file is very simple, and it seems to work fine. I've added it as an attachment as well.

--- Portfile.orig	2015-04-19 17:30:33.000000000 -0700
+++ Portfile	2016-04-22 05:11:34.000000000 -0700
@@ -31,6 +31,13 @@
 worksrcdir      ${name}/source
 set docdir      ${prefix}/share/doc/${name}
 
+default_variants   +norename
+
+variant norename description {Disable library entry-point renaming} {
+    configure.args-append \
+        --disable-renaming
+}
+
 subport ${name}-docs {
     conflicts           ${name}-doxygen-docs
     supported_archs     noarch

This is my first submission, so please let me know if I've done anything wrong. Thanks.

[mcglk (Ken McGlothlen)]

+norename variant patch for the icu Portfile.

[mcglk (Ken McGlothlen)]

I realize this was ambiguous, so I'll clarify: It does seem to have fixed our problem with the other application as well, which is no longer looking for an incorrect entry point.

[mf2k (Frank Schima)]

In the future, please Cc the port maintainers (port info --maintainers icu), if any.

[mcglk (Ken McGlothlen)]

Replying to mf2k@…: Thank you. I'll keep that in mind for next time.

[ryandesign (Ryan Carsten Schmidt)]

We don't use negatively-named variants anymore (e.g. variant name begins with "no").

Disabling entry point renaming by default would change the files installed by the port, which would warrant the port's revision being increased.

Wouldn't disabling entry point renaming cause all ports linked with the library to no longer work (because they were using the renamed entry points) and need to be rebuilt?

Wouldn't making this a choice that a user can select via variant mean that a port built against icu with the variant selected would not work with icu without the variant selected, and vice versa? This would wreak havoc given that we build binaries on our servers, using only default variants.

[mcglk (Ken McGlothlen)]

As to the first two points, I assumed those weren't really my call in the first place, and I expected that the patch wouldn't be accepted as is.

Suggestions for a variant name are welcome; I was guided in my choice by ‘boost’, which has both a +no_static and a +no_single variant by default (though I admit, I omitted the underscore). I'm perfectly willing to resubmit my patch with whatever more experienced port maintainers prefer.

As to “wreak havoc,” I would think that having entry points that didn't change names with every new version would actually be a plus for dynamic linking. Sure, there would be a need to force a rebuild on dependent ports, but only the first time. As the portfile says:

# Don't forget to increase the revision number of the dependents (e.g. boost)
# whenever the library version number changes. Thanks.

If the entry points didn't change names with version numbers, wouldn't that requirement go away? Or do programmers that use libraries such as icu prefer to link with version-specific entry points (in which case, why would one use dynamic linking in the first place)? (I'm not trying to be sarcastic; it's a genuine question.)

[ryandesign (Ryan Carsten Schmidt)]

The boost port's "no_single" and "no_static" variant names are a decade or more out of date and do not represent our best practices. They should really be converted to subports at this point.

As I understand the situation, icu offers a choice about whether the symbols that go into its libraries are suffixed with a version number or not. Whichever way we choose, those are the symbols other programs will expect to be in the library. If we enable the version number suffix feature, I don't think other programs will explicitly use a version number suffix, but I think that the icu headers will do so automatically when a symbol without the version number suffix is used. As such, I don't think it matters to other software whether or not we use this feature.

Since this choice affects how all other software uses icu, we cannot leave it up to the user to change this via a variant. If we did, and the user changed it from the default that we use on our build machines, anything they had installed via a binary from our build machine would be broken.

So we have to either always rename symbols, or always not rename symbols. And since the default is to rename symbols, and that has been working fine for us so far, I see no reason to change it.

No, disabling symbol renaming would have no bearing on the fact that we need to increase the revision of ports that use the library when the major version number increases. This is simply the reality of what a major version number increase means: it means the library is not backward compatible, at least not in terms of ABI. (If it were ABI-compatible, the developers would not have increased the major version.) It may be API-compatible in that recompiling the other software would be enough, or it may be API-incompatible, requiring source code changes in the other software. Either way, the library major version number is part of the library's filename and install_name, so any other software linking with the old library major version number will simply fail at runtime with a message that the library file cannot be found. Hence we must revbump to rebuild.