I am using grub 2.02. When I attempt to load a module (for testing purposes), the loader fails, with an error " incompatible license". This is one of those obscure problems which seems to be related to version control issues. I haver tried the following licenses, and have also tried using no license.
MODULE_LICENSE("Dual BSD/GPL");
MODULE_LICENSE("GPLv2+");
MODULE_LICENSE("GPL");
MODULE_LICENSE("GPLv3+");
MODULE_LICENSE("GPLv3");
Can anyone tell me what is the magic word to get rid of this error message?
The macro is called GRUB_MOD_LICENSE, not MODULE_LICENSE.
Additionally, the licenses considered valid are (as extracted from grub-core/kernel/dl.c):
GPLv3
GPLv3+
GPLv2+
By the way - GRUB 2.02 is not released: the latest tag available is grub-2.02-beta2
Related
I want to cross-build partprobe (e.g. parted-3.1 from [here] ) for an ARMv7-controller but keep getting error messages concerning libuuid and uuid_generate.
Actually I only need partprobe which may not even rely on that uuid_generate function, but I don't see any options in the configure script to disable any features.
I've successfully cross-built software before using the BPS as well as using the ARM toolchain provided by my distribution (Mint 17).
Here's what I've tried so far:
1) Using the manufacturer's BSP
I have a board support package that provides libraries and headers as well as a toolchain:
/path/to/bsp/_rootfs/lib/libuuid.so.1
/path/to/bsp/_rootfs/lib/libuuid.so.1.3.0
/path/to/bsp/board-support/linux-3.2.0-psp04.06.00.11/include/linux/uuid.h
/path/to/bsp/linux-devkit/am3352/bin/
When I invoke
./configure \
--libdir=/path/to/bsp/_rootfs/lib/ \
--includedir=/path/to/bsp/board-support/linux-3.2.0-psp04.06.00.11/include/ \
--bindir=/path/to/bsp/linux-devkit/am3352/bin/ \
--with-sysroot=/path/to/bsp/_rootfs \
--host=arm-linux-gnueabihf
I get the following error
checking for uuid_generate in -luuid... no
configure: error: GNU Parted requires libuuid - a part of the util-linux-ng package (but
usually distributed separately in libuuid-devel, uuid-dev or similar)
This can probably be found on your distribution's CD or FTP site or at:
http://userweb.kernel.org/~kzak/util-linux-ng/
Note: originally, libuuid was part of the e2fsprogs package. Later, it
moved to util-linux-ng-2.16, and that package is now the preferred source.
The uuid.h and libraries are available, so I thought the configure script should not complain, but the error seems to be misleading. The header uuid.h is available but does not contain a uuid_generate function declaration, while the library contains such a function (checked with nm -D).
I'm not sure what to do with that...does the BSP contain incompatible version of the header and the library?
However the busybox binary contains wget which seems to use uuid_generate...at some point it must have worked.
Replacing the original uuid.h with a uuid.h.in from the /path/to/bsp/docs/am3352/licenses/e2fsprogs/ (which contains uuid_generate) still results in the same error.
2) Using the Linux distro's ARM-environment
I also tried using the ARM-toolchain provided by my Linux distribution (packages gcc-arm-linux-gnueabihf, libuuid1:armhf)
aptitude install uuid-dev:armhf
shows conflicts with the x86 package of uuid-dev, but there are already available:
/usr/arm-linux-gnueabi/include/linux/uuid.h
/usr/arm-linux-gnueabihf/include/linux/uuid.h
/lib/arm-linux-gnueabihf/libuuid.so.1
/lib/arm-linux-gnueabihf/libuuid.so.1.3.0
BTW: None of those two header files includes a string uuid_generate, while the libraries do.
Invoking
./configure host=arm-linux-gnueabihf
runs without errors, but creates a Makefile that lacks any info on the cross-build environment.
BTW: Invoking make anyway exits with error; trying the same with the current source code from git://git.savannah.gnu.org/parted.git configures and builds successfully, but no magic involved: the result are libraries/binaries for x86 and not for ARM.
Right now I'm at my wits' end - so my question is:
Can someone see the problem(s) I'm missing?
During the development of a small project using statically linked OpenSSL 1.0.2e I encountered a strange error in VS13:
Error LNK2001: unresolved external symbol _BN_is_zero
Quite often, this happens when you forget to properly liked .lib file in the project properties, but all of the properties were double-checked - they are correct.
Configuration - Release, MT, libs are MT, bh.h included.
And even if one of the libraries is not linked properly, I should have multiple compiler errors complaining about unresolved external symbols of all the elements used in the project, but in my case unresolved external symbol is the only BN_is_zero.
After quick googling there wasn't found any issues, related to openssl bugs and I guess that the problem resides at my project.
Any tips will be appreciated.
UPD
Here is some screens:
I actually forked the csrp github project and compiled it against the particular openssl libraries you are pointing at. I had to slightly modify test_srp.c and src.c to add some code that isn't available on VS2013. A fork of csrp with the changes applied and the visual studio project for VS2013 to compile it can be found here:
https://github.com/sigmoidal/csrp
Note that you need to change the paths of the openssl path on BOTH the debug and release versions to reflect your VS Configuration Properties:
C/C++ > General > Additional Include Directories
D:\dev\openssl\openssl-1.0.2e-vs2013\include
(you should not point it to $openssl_path/include/openssl, it will not work)
and also:
Linker > Input > Additional Dependencies:
For release configuration:
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\libeay32MT.lib
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\ssleay32MT.lib
For debug configuration:
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\libeay32MTd.lib
D:\dev\openssl\openssl-1.0.2e-vs2013\lib\ssleay32MTd.lib
(notice the "d" suffix on debug libs)
Compiled ok for me.
I'm guessing here, but according to the OpenSSL source BN_is_zero is defined as a macro:
http://osxr.org/openssl/source/crypto/bn/bn.h#0407
So perhaps the module that is compiled into srp.obj is making a call to BN_is_zero but is not including bn/bn.h and in the absence of a prototype the compiler is generating a default one.
If this is the case, including the bn.h definitions should avoid the linker error.
It was tricky, but I've finally solved it based on the Drew MacInnis tips.
The matter is that openssl 1.0.2e broke the BN_is_zero functionality by simply removing the macros-containing header from sources. So, the solution is:
Download the bn.h include file from 1.0.1h (or here)
Place bn.h to %OPENSSL_HOME%/crypto/bn directory
Change #include <openssl/bn.h> for #include <../crypto/bn/bn.h>
Over the last few days I've been tinkering with mod_pLua on Windows (https://sourceforge.net/projects/modplua/ or https://github.com/Humbedooh/mod_pLua).
The pre-built Windows binary works a treat, except it doesn't seem to have been compiled with mod_dbd support for database connectivity. The documentation suggests that to enable this feature you must compile with a certain tag, so I've been trying to compile the module in VS2010 - hoping that I'll be able to get mod_dbd support working at some point - but I've run in to a snag. It just will not compile.
What I've done so far:
Included apache/include and apache/lib, which got rid of a lot of
errors
Included lauxlib.h, lua.h, luaconf.h and lualib.h from Lua 5.2, which got rid of a lot of errors
Compiled a .lib file from Lua 5.2 sources and included it, which fixed a few errors
The errors I'm getting at the moment are:
error LNK2019: unresolved external symbol _luaL_openlib referenced in function _lua_dbopen C:\Users\Michael\Desktop\Projects\C\mod_plua\mod_plua.obj
And a plethora like this:
IntelliSense: a value of type "const char ()(cmd_parms *cmd, void *cfg, const char *arg)" cannot be used to initialize an entity of type "cmd_func" c:\users\michael\desktop\projects\c\mod_plua\mod_plua.h 394 5
As I'm not a C/C++ native, I only have a vague idea of what's wrong, and have likely done something wrong in my attempts to fix the issue. If someone could guide me in the right direction (or better yet, write a little instructional on how to compile the module from start to finish) I would be so happy.
I've uploaded my VS2010 project files and source here: https://dl.dropboxusercontent.com/u/51243175/mod_plua_vs2010.7z
Self-answer:
The primary reason for the failure to compile was the Lua .lib file. The Microsoft compiler does strange things when dealing with C code, so I got an appropriately compiled version of the .lib from the LuaBinaries SourceForge repository (http://sourceforge.net/projects/luabinaries/) - specifically, 5.2.3/Windows Libraries/Dynamic/lua-5.2.3_Win32_dll10_lib.zip (which is compiled for VS2010).
This didn't enable mod_dbd support, which requires headers and sources from the Apache APR project, but it did allow successful compilation.
You should not be using mod_pLua really, I haven't worked on that for nearly 3 years ;) You should use mod_lua instead, which comes bundled with httpd and works pretty much the same way (although it does not support the php-like scripting that mod_pLua does)
For DBD specific setups (especially how to use it on Windows), see http://modlua.org/api/database
I was compiling some code I found on the internet and I was given the error
calcCookie.c:1050: warning: ‘HMAC’ is deprecated (declared at /usr/include/openssl/hmac.h:103)
calcCookie.c:1050: warning: ‘EVP_sha1’ is deprecated (declared at /usr/include/openssl/evp.h:666)
when I googled the libraries I couldn't find anything about the symbols being deprecated, I just found a reference to the symbols I used.
http://www.openssl.org/docs/crypto/hmac.html etc.
Do you have any tricks/websites that you can use to find the replacement for deprecated symbols?
First of all, try to find up-to-date documentation for the library.
If that does not work, the warning message from the compiler tells you the file name and line number where the symbol was declared. Look there and hopefully you fill find a comment that explains why it is deprecated and what the alternative is.
If that does not work, then you can look at the version history of the library. Find the first revision where the symbol was marked as deprecated. Look at the commit message and the other changes that were happening around the same time to get a clue about what is going on.
Are/Were you by chance compiling on OSX?
Apple has decided to deprecate OpenSSL and replace it with CommonCrypto.
Why is Apple Deprecating OpenSSL in MacOS 10.7 (Lion)?
Hey there,
following problem:
I'm using a rather weird linux distro here at work (Centos 5) which seems to have an older kernel (or at least some differences in the kernel) and you can't simply update it.
The program I need to install needs a function crypto_destro_tfm (and prob some more, but this is the only error at this point) which is included in the file linux/crypto/api.c - so I assume its in the kernel module crypto_api. Problem is: On my distro, I don't even have an crypto/api.c and even though I do have a module crypto_api.ko it seems that this function isn't in there.
My plan is the following: Take the crypto_api from a newer linux distro and then compile it and load the module into my centos.
Now I hope that some of you can tell me what I need to do to rebuild and replace that module. Of course I do have all the source files from a newer kernel. (Just to remind you: I can't simply recompile and use a newer kernel, b/c centos sucks in this way)
Thank you
FWIW: Here's the exact error
WARNING: "crypto_destroy_tfm" [/home/Chris/digsig-patched/digsig_verif.ko] undefined!
There is a good chance backporting API change in an older kernel will lead to a cascade of problem. Let's suppose you backport crypto api of version 2.6.Y to your local version, 2.6.X
Now you have the following situation :
module crypto api export 2.6.Y functions
your external module might be Happy with that situation
all other module that depends on version 2.6.X of the crypto API will complain.
But wait, I can backport recent kernel code into all the modules that complain, and here we go... Oops, but then we have the former situation, but now each backported module might trigger a similar situation.
If you can't update the CentOS kernel, because the CentOS kernel has a lot of custom code you are afraid to loose when going with a "vanilla" kernel, then you may find that it is an easier task to "downgrade" your external module :
Look at the current crypto API (for example using lxr.linux.no)
Look at your kernel version of this API
Try to see how the new API could be replaced with call to the old API to provide a similar function.
Modify your external module to use the old API instead of the new one.
In any case, you may not be able to replace your kernel with a vanilla one, but you should at least be able to rebuild it, and then to patch it and rebuild it etc... If you can't do this simple task, then I don't think backporting anything will be successful.
Try downloading the SRC RPM from a newer version of CentOS which has the module and recompile the RPM on your CentOS 5:
rpmbuild --rebuild kernel-X.XX-X.src.rpm
I don't have a copy of CentOS to compare with so you will want to read the man page on rpm/rpmbuild, but I've found recompiling the whole package which includes the kernel and all it's modules to be safer than trying to just porting one module from a newer kernel. I do this occasionally on Debian/Ubuntu when I need a newer package for something.