openssl-native doesn't play nice with sstate (mirrors)?

openssl-native doesn't play nice with sstate (mirrors)?

[Jerrod Peach]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

All,

I ran into an issue yesterday when trying to run the openssl binary that
comes out of the openssl-native package.  I had previously built
openssl-native in another location as another user, and that sstate entry
was copied out to an sstate mirror.  I then built openssl-native in my
personal workspace.  That worked fine; I got a cache hit from the sstate
mirror.  However, when trying to run openssl-native (just the openssl
binary itself, no arguments), I got this fatal error:

140295424861888:error:0200100D:system library:fopen:Permission
denied:bss_file.c:169:fopen('<path to original build
directory>/openssl.cnf','rb')
140295424861888:error:2006D002:BIO routines:BIO_new_file:system
lib:bss_file.c:174:
140295424861888:error:0E078002:configuration file routines:DEF_LOAD:system
lib:conf_def.c:199:

In this case, it seemed openssl wanted to find a config to its original
build location, but it wasn't allowed to find it in this case, because that
directory was owned by a different user.  Grepping through the binary and
openssl's *.so files, I found a ton of references to the original build
directory.  I was finally able to get around this behavior by setting a
couple of environment variables to point to the current directory of the
binary (namely, OPENSSLDIR and OPENSSL_CONF), but is this expected
behavior?  Is there some workaround that gets prevents the user of
openssl-native from having to set those environment variables?  Or, is this
a bug in the way openssl-native is built?

Kind regards,

Jerrod

[-- Attachment #2: Type: text/html, Size: 1715 bytes --]

Re: openssl-native doesn't play nice with sstate (mirrors)?

[Chris Larson]

On Fri, Oct 19, 2012 at 9:03 AM, Jerrod Peach <peachj@lexmark.com> wrote:
> In this case, it seemed openssl wanted to find a config to its original
> build location, but it wasn't allowed to find it in this case, because that
> directory was owned by a different user.  Grepping through the binary and
> openssl's *.so files, I found a ton of references to the original build
> directory.  I was finally able to get around this behavior by setting a
> couple of environment variables to point to the current directory of the
> binary (namely, OPENSSLDIR and OPENSSL_CONF), but is this expected behavior?
> Is there some workaround that gets prevents the user of openssl-native from
> having to set those environment variables?  Or, is this a bug in the way
> openssl-native is built?

I'd suggest adding a create_wrapper call to the recipe to emit a shell
script wrapper which sets those variables, then the standard sstate
sed'ing of the sysroot path will occur to the wrapper, and it will
always work. We do this in a number of other recipes to work around
relocation issues.
-- 
Christopher Larson