cvs commit: ports/math/mpfr Makefile distinfo

[b. f.]

On 10/7/11, Alex Dupre <ale at freebsd.org> wrote:
> b. f. ha scritto:
>>> From ${WRKSRC}/src/Makefile:
>>
>> libmpfr_la_LDFLAGS = $(MPFR_LDFLAGS) $(LIBMPFR_LDFLAGS) -version-info
>> 5:0:1
>>
>> So this should have included a libmpfr major version bump in the
>> pkg-plist:
>
> No, sorry. We have the ltverhack exactly to avoid unneeded version bump.
> Have you actually tried to build the port?

Yes, of course, and it failed as I mentioned.  But I see that I was a
little too hasty in looking for the cause -- I am running recent
-CURRENT, and the build was actually broken by:

http://lists.freebsd.org/pipermail/svn-src-head/2011-October/030170.html

which triggered a refresh build on my machine that installs the shared
library with the wrong version number, which is what I saw when I
looked at the tail of the build log.  So the problem is not with this
port, but with the hack that was added to /usr/share/mk/bsd.port.mk --
my apologies.

>
>> Also, I wonder
>> if some of the dependent ports have come to depend, explicitly or
>> implicitly, upon a thread-safe mpfr?
>
> Does my commit message say that I've disabled thread-safe support or
> that I haven't enabled it?

How am I to answer this rhetorical question?  (I think that I might be
forgiven for wondering in passing if the change has any consequence,
since you brought it up in the commit message.) Your commit message
says "Do not enable thread-safe support" -- as you well know -- but
you have added an explicit "--disable-thread-safe" to CONFIGURE_ARGS.
For the new version of the port, thread-safe support depends on the
auto-detection of TLS support, but before it had to be explicitly
enabled.   So are you suggesting that if anything is broken by the
lack of mpfr thread-safety, then it was already broken?  If so, it
would have been simpler just to say so.

b.