On Jul 9, 2009, at 1:07 AM, Bryan Blackburn wrote:
On Wed, Jul 08, 2009 at 09:21:40PM -0700, Scott Haneda said:
[...]
http://trac.macports.org/wiki/FAQ#WillMacPortslinktosystemlibrariesratherthanitsown
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.
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.
Ok, I always run on debug mode, I will look out for those thing. When
I am installing something like ASSP, it has 20 or so p5's to do, so
there is a lot going by. I will do them one at a time and look at each.
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.
port upgrade openssl took all of 5 seconds, if that. I would have
expected it to take longer, if it had to rebuilt modules that depended
on it. Or are these libs and headers just files that get pointed to,
and not built into the binary. The binary just holds paths to the
libs and headers?
So, If I were to take a binary that was made on an intel machine, and
take it to another identical intel machine, but did not bring along
the libs and headers, it would not work until I did so?
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.
ASSP is a email proxy, it supports SSL and TLS mostly by using p5's to
make it all happen. The setup is Internet -> ASSP -> MTA
If I made a SSL or TLS enabled connection directly to the MTA on port
25, SSL and/or TLS will work fine.
If I make a connection to the ASSP proxy, it works some of the time.
I send a email in the command line:
`mail u...@remote-mta-machine`
This will always work
`mail u...@assp-proxy` this simply hits port 25, which is set to proxy
to the far end MTA. It fails the SSL parts entirely. Some hosts that
I send the `mail` command from work, others do not. I subscribed to a
few mailing lists, some get through, some do not.
I can use openssl as a client, and connect to the remote far end MTA
just fine, connecting to ASSP, and I get the connection, but that is
as far as I get.
I have little knowledge of how this all works, so it is hard for me to
even make test cases.
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.
Perhaps I am in this mess. I made many of these p5 port files, and
most just amounted to finding an older p5, editing the name and
version, dropping in a description, maintainer, and hash. Maybe there
was more research into those port files I needed to do. I looked at
cpan for any dependencies, and add those as needed, but that is as far
as I usually took it, other than running it, and if there were test
cases, giving them a quick try. If it loaded, I considered it ok.
Last night, I ran sudo port -df uninstall all and removed everything.
I then ran sudo port -d install assp. It all went in, in one go, no
errors, that was nice.
However, I am still not able to get ASSP to work in SSL mode.
I know what p5's ASSP installs, and can easily tell what dependencies
I need to track down to look at. However, those depend on perl, which
was installed, and curses was installed; a lot of other things too.
Can I be reasonably confident, if any of those use openssl libs and
headers, I need not run otool on them, and do any checking?
Can you suggest any automated why to run otool against all the p5's
and anything else you can think of, so I can find out if this is the
area of my problems.
This very well could be a bug in ASSP, and I am yet to find more than
one person who has gotten this to work. So far, I am having a hard
time finding the person who wrote the SSL sub routines in ASSP, to
even get to the point where it can be debugged.
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.
Agreed. I have been delivering email from several machines that can
not deliver to ASSP, for years. Millions of messages sent from php
scripts that end up on some server somewhere. I am confident that
things are ok on those sending machines. I am pretty sure the openssl
versions on the MUA sending side, and the destination receiving side
are ok. So something is happening on the ASSP machine. (I am running
the ASSP proxy on a separate machine)
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:
<http://trac.macports.org/changeset/12976>
I used upgrade. I suspect this was PATH related, I may have been
logged in as a user that did not have the .profile set up so it was
polling the Apple supplied version.
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...
Can you show me how you tried them, I was not able to get them to
work, but all I did was `perl filename` which probably was not a valid
way to test. I really do not know perl, or SSL vocabulary well enough
to properly test these out.
Thanks Bryan.
--
Scott * If you contact me off list replace talklists@ with scott@ *
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
