RE: compilation problem for xscale.
My apologies to all for mis-remembering what package the issue was relating to - it was with an iscsi target (IET, which is certainly GPL!). I was working with both openssl and IET when I had this problem, and for some reason I associated it with openssl instead of IET. Sorry for the extra noise! (Since I mis-remembered the kernel module that I was having trouble with, unless someone wants to discuss the issues of cross-compiling kernels (and executables) and getting GPL-only symbol exporting to work, I expect this is my last posting here on this subject unless others wish to discuss cross-compiling and EXPORT_SYMBOL_GPL here). If anyone cares to know what actually is the story: IET (iSCSI Enterprise Target) uses the crypto interface. I am cross-compiling to arm/xscale - the kernel using the 'arm-2006q3' toolchain, and executables and modules using the 'armv5l-linux' toolchain. But the resulting ietd fails to load because it cannot 'find' the crypto symbols. (If I change the export to non-GPL and rebuild the kernel, ietd loads fine, so it's a "cannot resolve symbol" issue, not a binary incompatibility issue). After some fooling around, my current theory that my problem is related to the fact that this is a cross-compiled kernel. I grepped every single file in my kernel build tree, and no non-source file anywhere has 'crypto_register_alg' inside it. And I don't see ANY of the other crypto GPL symbols in the symbol table! (System.map) So, I'm trying to find anyone who has cross-compiled a kernel for xscale and been able to load GPL kernel modules which used the GPL kernel symbols. Or, put another way - I want to find out if KERNEL_EXPORT_SYMBOL_GPL works under a cross-compile environment. (I am using 'arm-2006q3' toolchain) The first part of my initial email follows, but changed to fit reality. Thanks! Rusty (the original poster) -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Carruth, Rusty Sent: Friday, May 21, 2010 10:43 AM To: openssl-users@openssl.org Subject: compilation problem for xscale. I've compiled a GPL module (IET) to run on an xscale, and it worked fine except for one major issue - I could not load the __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: compilation problem for xscale.
Rusty Carruth wrote: > I would have thought that OPENssl, for which I have the source, would > have met the requirements to use the _GPL symbols in the kernel. The requirement is that the module claim that it is available under the GPL by containing a specific license declaration. You can fix this two ways: 1) Modify the Linux kernel so that this requirement is removed. The GPL explicitly give you the right to do this if you wish to. 2) Modify your module so that it claims it is available under the GPL even though it is not. The functional exception to copyright gives you the right to do this. Note that making sure you do not violate copyright law is your responsibility. While you are permitted to bypass technical restrictions (GPLv2 grants you that right), if you choose do so, it is still entirely your responsibility to comply with the license. Specifically, GPLv2 does not permit you to create a derivative work and distribute that entire work under any terms not compatible with the GPLv2. Since you cannot make OpenSSL available under compatible terms, you must not distribute a work that is derivative both of OpenSSL and the Linux kernel. (If you are unclear on what this means, I'd strongly urge you to consult a lawyer.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: compilation problem for xscale.
On Tue, May 25, 2010 at 19:09, Carruth, Rusty wrote: > Should I send this request to the developers list rather than here? > > If so, I'll be happy to do so... > > In any case, the short version is: I cross-compiled openssl for target > xscale, and could not load the kernel module because some of the symbols > (e.g. crypto_register_alg) apparently because they were exported using > EXPORT_SYMBOL_GPL, and openssl did not convince the kernel that it could > use the _GPL symbols. Or at least that's what it appeared to be. > > I would have thought that OPENssl, for which I have the source, would > have met the requirements to use the _GPL symbols in the kernel. > > So - the question: Is there some trick I need to do to convince the > kernel (2.6.18.8) to allow openssl (0.9.81) kernel module to load? > (Without breaking the _GPL symbols) err, openssl doesnt provide any linux kernel modules (that i'm aware of). what module exactly are you trying to load ? and where did you get it from ? -mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
