<div dir="ltr">David,<div><br></div><div>Would you please take over as maintainer of the port?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 4, 2014 at 4:54 PM, David Evans <span dir="ltr">&lt;<a href="mailto:devans@macports.org" target="_blank">devans@macports.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 4/4/14 4:01 PM, Ryan Schmidt wrote:<br>
&gt;&gt; On 4/4/14 1:22 AM, Ryan Schmidt wrote:<br>
&gt;&gt;&gt; You should use a specific version of perl instead, like perl5.16.<br>
&gt; Maybe I take that back, because:<br>
&gt;<br>
&gt; On Apr 4, 2014, at 07:44, Eric Gallager wrote:<br>
&gt;<br>
&gt;&gt; I thought we were doing variants now, when the dependency is for more<br>
&gt;&gt; than just the &quot;perl&quot; executable, at least:<br>
&gt;&gt; <a href="https://trac.macports.org/ticket/43193" target="_blank">https://trac.macports.org/ticket/43193</a><br>
&gt; In this case, the dependency isn’t for more than just the perl executable, is it? The port does build and install perl modules, but it installs them in a pidgin-specific location, not in the versioned directory for whatever version of perl it found. And it doesn’t appear that the path to perl gets baked into any installed files. So maybe the perl version doesn’t matter after all.<br>

</div>Mostly true with the exception of the baked-in part.  The port builds<br>
<br>
/opt/local/lib/purple-2/perl.so<br>
<br>
which has a binary dependency on the versioned libperl.dylib that<br>
belongs to the perl it configured with.<br>
<br>
In my mixed versioned test case this is perl5.12<br>
<br>
otool -L /opt/local/lib/purple-2/perl.so<br>
<br>
/opt/local/lib/purple-2/perl.so:<br>
    ...<br>
<br>
/opt/local/lib/perl5/5.12.4/darwin-thread-multi-2level/CORE/libperl.dylib (compatibility<br>
version 5.12.0, current version 5.12.4)<br>
    ...<br>
<br>
This is caused by this line in <a href="http://configure.ac" target="_blank">configure.ac</a>:<br>
<br>
PERL_LIBS=`$perlpath -MExtUtils::Embed -e ldopts 2&gt;/dev/null |$sedpath<br>
&#39;s/-lgdbm //&#39;`<br>
<div class=""><br>
On Apr 4, 2014, at 10:59,<br>
<br>
David Evans wrote:<br>
&gt;&gt; Unfortunately that doesn&#39;t work in this situation.  <a href="http://configure.ac" target="_blank">configure.ac</a> needs<br>
&gt;&gt; to be modified to respect<br>
&gt;&gt; configure.perl before a version specific perl can be used.<br>
&gt;&gt;<br>
&gt;&gt; <a href="http://configure.ac" target="_blank">configure.ac</a> uses this code to test for perl:<br>
&gt;&gt;<br>
&gt;&gt;        AC_PATH_PROG(perlpath, perl)<br>
&gt;&gt;        AC_MSG_CHECKING(for Perl compile flags)<br>
&gt;&gt;        PERL_CFLAGS=`$perlpath -MExtUtils::Embed -e ccopts 2&gt;/dev/null`<br>
&gt; I’ve changed my mind about the necessity of this, but if we did want to use a specific perl, patching the configure file would not be necessary; you can just add this to configure.args:<br>
&gt;<br>
&gt; ac_cv_path_perlpath=${prefix}/bin/perl5.16<br>
&gt;<br>
&gt;<br>
</div>Yes, this works (just tried it on a test build).<br>
<br>
Actually, if I were the maintainer of this port, I&#39;d put perl, tcl and<br>
tk in variants as I&#39;m not sure how much demand<br>
there is for these bindings to libpurple and installing them in pidgin&#39;s<br>
own tree makes them inconvenient to use.<br>
<br>
Unfortunately, the maintainer has been AWOL for some time so it&#39;s<br>
cumbersome to make changes.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
macports-dev mailing list<br>
<a href="mailto:macports-dev@lists.macosforge.org">macports-dev@lists.macosforge.org</a><br>
<a href="https://lists.macosforge.org/mailman/listinfo/macports-dev" target="_blank">https://lists.macosforge.org/mailman/listinfo/macports-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>&quot;America was founded by men who understood that the threat of domestic tyranny is as great as any threat from abroad. If we want to be worthy of their legacy, we must resist the rush toward ever-increasing state control of our society. Otherwise, our own government will become a greater threat to our freedoms than any foreign terrorist.&quot;<br>
 - Ron Paul, Texas Straight Talk, May 31, 2004
</div>