Bryan Blackburn blb at
Thu Jul 9 01:07:38 PDT 2009

On Wed, Jul 08, 2009 at 09:21:40PM -0700, Scott Haneda said:
> >
> ><>
> >
> >and the entry following that.
> Thanks.  One thing that is not clear, is you say "make sure things
> link to".  How does one do that, the docs above do not explain that.
> When I make a port file, especially in the case of p5's, it is pretty
> simple.  I have never seen any way to specify any paths for linking
> to any dependencies libs.

Yeah, the FAQ is more user-oriented rather than port maintainer oriented.
Explaining the how is extremely complicated due to the varied nature of
software (does it build executables, libraries, bundles, frameworks, etc)...

By default though, port should be telling most software how to find the
right headers and libraries installed by MacPorts with various
configure-time settings.  You should be able to see this if you run port in
debug, eg for p5-io-socket-ssl:

DEBUG: Environment: CFLAGS='-pipe -O2 -arch i386' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-pipe -O2 -arch i386' MACOSX_DEPLOYMENT_TARGET='10.5' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-pipe -O2 -arch i386' LDFLAGS='-L/opt/local/lib -arch i386' FCFLAGS='-pipe -O2 -arch i386' OBJC='/usr/bin/gcc-4.0' INSTALL='/usr/bin/install -c' PERL_AUTOINSTALL='--skipdeps' OBJCFLAGS='-pipe -O2 -arch i386' FFLAGS='-pipe -O2 -arch i386' CC='/usr/bin/gcc-4.0'

Note the -I/opt/local/include and -L/opt/local/lib in there.

> When I run that on the machine I am having issues with:
> $otool -L /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-*/auto/Net/
> SSLeay/SSLeay.bundle
> /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Net/SSLeay/
> SSLeay.bundle:
> /opt/local/lib/libssl.0.9.8.dylib (compatibility version 0.9.8,
> current version 0.9.8)
> /opt/local/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8,
> current version 0.9.8)
> /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.3)
> /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version
> 47.1.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 111.1.4)
> I get one more line than you do, not sure what that means.

I believe libmx can be safely ignored so it looks fine, especially the
OpenSSL libs (libssl and libcrypto) as well as libz, all being the
MacPorts-provided ones.

> I updated openssl, `sudo port updgrade openssl`
> 	$which openssl
> 	/opt/local/bin/openssl
> 	$/opt/local/bin/openssl version
> 	OpenSSL 0.9.8k 25 Mar 2009
> Does that mean, that p5-net-ssleay will now use the updated version?
> Maybe I do not get this, and openssl updates just the binary, and has
> nothing to do with the libs.

Upgrading the port upgrades all bits for it, any binaries, libs, headers,
etc.  So if 'openssl version' says 0.9.8k, then the headers and libraries
should be that version as well.

> What I do know, is ASSP needs p5-net-ssleay, there is a suspicion
> that the openssl version I am working against is too old, or too
> buggy, so I need to try to solve that.

Hard to say without knowing how things aren't working; I know some software
doesn't like when you compile using one version of headers then link against
a different version of libraries.

> I do not know if I just need to update openssl via ports, or if I
> need to remove all related perl modules, and install them again, or
> if I need to remove all of ASSP and install that again as well to get
> the new bits.

Worst case would call for rebuilding anything which links against OpenSSL,
but also make sure everything which wants it declares a dependency on the
port.  Otherwise, you end up with one port without the dependency and then
it may link against the system OpenSSL, then another port comes along with
that dependency and installs it then links against MacPorts' OpenSSL.
If you try using those two together, you get a mess.

> Toss in postfix, which also uses openssl as well and I am not sure
> what and where I need to look to update things.  Add to that, ASSP is
> on a different machine than postfix, and I have two places I get to
> answer these questions.  Ugh :)

If they run on different servers, then precise OpenSSL versions should
technically not matter, as long as the SSL/TLS protocols are properly
followed.  Of course if there's a bug in the protocol handling of a given
version, then you have a problem.

> >>It was simple enough to port update openssl and get a newer version.
> >>And if I type `which openssl` I get the new version in the macports
> >>area.
> >>/opt/local/bin/openssl
> >>
> >>However, when it comes to apps that use IO::Socket::SSL, which in
> >>turn, will call openssl, how can I be sure it is using the correct
> >>openssl, not the apple one?
> >
> >Since it goes through Net::SSLeay to make OpenSSL calls, the best
> >method is
> >the one I list above using otool, to see where the binding to
> >OpenSSL is in
> >fact linked.
> I see where it is linked, and before, openssl version returned
> OpenSSL 0.9.7l 28 Sep 2006

This sounds like the system OpenSSL so perhaps when you ran it that time you
didn't have the openssl port installed yet?

> So, by seeing "OpenSSL 0.9.8k 25 Mar 2009" in the version that I now
> have installed, and seeing 0.9.8 returned by otool, does that mean
> that when I ran port update openssl those files were updated?  Or,
> does it mean that macports already happened to have the 0.98 versions
> in place, and I just happened to get to use those?

Hard to say, if you used 'port install openssl' then you didn't have the
port installed at all; if you used upgrade, then that's a bit odd as the
openssl port has never been at 0.9.7l, it went from 0.9.7g to 0.9.8 four
years ago:


> >>There are no patche for IO::Socket::SSL, so it is just being
> >>installed, nothing changed in it to point to a specific openssl.
> >>
> >>Further, p5-event none of the example in IO::Socket::SSL work for me.
> >
> >I'm not sure what you mean here.
> Me neither :) I had something on the clipboard I did not mean to
> have.  I think I meant that, in the IO::Socket::SSL download, there
> are a set of sample files, and running them, none of them work, and
> all barf with errors.

I tried a couple of them, the client and server are able to talk to each
other, though that isn't too surprising since they are using the same
software; I also tried connecting to the server with the system openssl
command, and it was able to get the SSL cert just fine...


> Thanks
> -- 
> Scott * If you contact me off list replace talklists@ with scott@ *

More information about the macports-dev mailing list