Chris Zhu wrote:

> Now if I were to hook the same Makefile and configure options into the 
> sfwnv consolidation, and create packages, the resulting Ruby cannot load 
> the Openssl extension.

Well I don't know, but here's a thought that is probably wrong.
I don't see ENGINE_load_openssl in the openssl libcrypto.so that
we ship on my desktop:

{mike_s:yavin:936} nm /usr/sfw/lib/libcrypto.so | grep ENGINE_load_openssl
{mike_s:yavin:937}

but I _do_ see it in the one I build locally on my desktop:

{mike_s:yavin:937} nm /usr/local/lib/libcrypto.so | grep ENGINE_load_openssl
[3698]  |    851076|        96|FUNC |GLOB |3    |11     |ENGINE_load_openssl
{mike_s:yavin:938}

BTW, openssl is in ON not sfw - you might want to poke around
there in the source browser to see, but it sure appears to me that
we don't even compile eng_openssl.c (where that function lives)
into libcrypto so that would explain it. No idea why though, you
might ask that on some other list. Maybe opensolaris-code or
perhaps security-discuss (not sure where the openssl guys might
hang out)?


> Now, the symbol ENGINE_load_openssl shows up as undefined, irrespective 
> of which build of openssl.so I look at.  So I assumed that  vanilla Ruby 
> build "knew" where to look for this symbol, while the sfwnv Ruby build 
> did not.

It may well just assume any libcrypto will have that symbol and
decide to use it. Certainly my local ruby build references it but
is linked against /usr/sfw/lib, so if it was looking to see if
it was there it shouldn't still reference it. But I suppose it
might be worth looking to see if during configure it did look
for that function but you had a /usr/local/lib with openssl in it
that it found. But then the build forces the one in /usr/sfw/lib to be
used.

> So is there a property in an so file to tell the linker not to load 
> symbols that are not used? Or any other ideas about what could be 
> different compiler/linkers wise, about the sfwnv openssl.so(or Ruby) 
> that is causing this load to fail?

afaik in the sfwnv build we don't force linker flags on you, you control
that in your Makefile.sfw. Unless you're using the default rules instead
of running configure and such.

Your best bet might be to look at the logs for both builds of openssl.so
and see what exactly changes, maybe some variable you set in the
environment is overriding what ruby would do by default and you
need to restore that. LD_OPTIONS is usually safe but I think LDFLAGS
can be worrisome if you're not careful (with configure that is).

        Mike

Reply via email to