I'm trying to write some JNA code that accesses glibc, specifically functions defined in mmap.h.
I have tried to define it exactly as shown in man shm_open. The getuid() function call just before it works, but shm_open doesn't return.
I'm constrained to using JNA 4.4.0 and JNA Platform 3.4.0.
interface LibC extends Library {
LibC INSTANCE = Native.loadLibrary("c", LibC.class);
int shm_open(String name, int oFlag, int mode);
}
// ...
int fileDescriptor = LibC.INSTANCE.shm_open("/some_memory.123", O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
// ...
I expect a file descriptor to be returned, but I get these exceptions:
When I load "libc.so.6": java.lang.UnsatisfiedLinkError: Error looking up function 'shm_open': /lib/x86_64-linux-gnu/libc.so.6: undefined symbol: shm_open
When I load "c": java.lang.UnsatisfiedLinkError: Error looking up function 'shm_open': /usr/lib/jvm/java-8-openjdk-amd64/bin/java: undefined symbol: shm_open
Well, I figured out the issue while writing the question.
While getuid() and friends are defined in libc, shm_open and friends are defined in librt. I really should have realized that because the manpage for shm_open explicitly states "Link with -lrt", indicating it residing in the "rt" lib.
In short: I need a new interface for LibRT alongside LibC, loaded with name rt.
Related
I am using an extensive piece of code which compiles in Windows and Linux with gcc>=4.7. It is a utility to seamlessly generate mex functions in Matlab from m-scripts written by someone. I am having trouble compiling a short c script (not provided here) in Mac os x. I am using gcc-4.8 with C++11. It uses Boost library only for headers. The piece of utility code where it gets stuck is:
/* gets mxClassID, given C type>
eg. mx_class_id<float>()*/
template<typename T>
struct mx_class_id
{
operator mxClassID()
{
return static_cast<mxClassID>(boost::mpl::at<mxInverseTypeMap,T>::type::value);
}
};
required by
template<typename T>
mxArray* mxCreateScalar(const T & val)
{
//mxClassID cid=static_cast<mxClassID>(boost::mpl::at<mxInverseTypeMap,T>::type::value);
mxArray * arr=mxCreateNumericMatrix(1,1,mx_class_id<T>(),mxREAL);
mxSetValue(arr,val);
return arr;
}
What am I missing? Is it conflicting with built-in clang libraries? Or is it a header not specified (boost/mpl/at.hpp is included)? As I mention it does compile in Matlab for Windows and Linux.I have tried boost 1.51.0 (this is what we use) and also 1.56.0 (this is what Matlab uses) but I get the same error message.
The code I use to compile is
mex -v /usr/local/bin/gcc-4.8 -I path-to-boost-library -I path-to-private-library -I /usr/local/lib -std=C++11 script.cc
Here is the error message I am getting:
error: 'value' is not a member of 'boost::mpl::aux::wrapped_type <
boost::mpl::aux::type_wrapper < mpl_::void_> > ::type {aka
mpl_::void_}'
Any pointers or help appreciated. Thanks
This was resolved by the conflicting use of 'size_t' and 'unsigned long int'.
I think in Linux, Windows, size_t was employed in the code with the assumption it to be uint64_t. And it compiled in both.
However, for mac os x, it is either size_type or unsigned long int. This especially created problem because the code was matching c type to Matlab mex type with one-to-one mapping. In inverse mapping, with the use of size_t this one-to-one mapping was getting lost and instead became many-to-one. Once that was addressed it was easy to fix the rest.
I have a kernel module which was probably written for the 2.6xx kernel version. Now I currently want to plug that module onto kernel version 3.1x and above. I have tweaked and changed the code and apparently now there is compilation error except the below mentioned warnings.
WARNING: "do_mmap_pgoff" [/home/abdullah/Downloads/my_mod.ko] undefined!
WARNING: "putname" [/home/abdullah/Downloads/my_mod.ko] undefined!
WARNING: "get_task_cred" [/home/abdullah/Downloads/my_mod.ko] undefined!
Now when I checked my kernel Module.symvers I did not find all three of the functions in it for exports. Which results in a fatal error when inserting the module. Now my question: Does anybody know the alternative to these functions? Any help will be really appreciated. Below is a sample function which illustrates the scenario as the complete function is to long.
int function_1(const char *fname)
{
struct cred *task_cred;
struct filename *filename = NULL;
filename = getname(__user(fname));
task_cred = (struct cred *)get_task_cred(current);
putname(filename);
filename = NULL;
return 1;
}
Well, there is another way also which is bit unsafe, any body who is not on a production system he can export these function in the kernel source file as I did
I'm using 64-bit gcc-4.8.2 to generate a 32-bit target, and my machine is 64-bit. I'm using c++11 concurrency features such as thread, mutex, conditiona_variables and etc.
The linker gave the above error message when trying to link the executable. libMyLib is also part of the project.
libMyLib.so: undefined reference to '__gthrw___pthread_key_create(unsigned int*, void (*)(void*))
nm libMyLib.so | grep pthread_key_create shows:
U _ZL28__gthrw___pthread_key_createPjPFvPvE
w __pthread_key_create##GLIBC_2.0
where is the symbol 'ghtrw___pthread_key_create' from? I tried adding '-lpthread(-pthread)' as compiler flag, but it does not help.
More information. nm libMyLib.so | grep pthread shows other symbols such as _ZL20__gthread_mutex_lockP15pthread_mutex_t is defined
where is the symbol 'ghtrw___pthread_key_create' from?
It is defined in GCC's "gthreads" abstraction layer for thread primitives, in the gthr-posix.h header.
#if SUPPORTS_WEAK && GTHREAD_USE_WEAK
# ifndef __gthrw_pragma
# define __gthrw_pragma(pragma)
# endif
# define __gthrw2(name,name2,type) \
static __typeof(type) name __attribute__ ((__weakref__(#name2))); \
__gthrw_pragma(weak type)
# define __gthrw_(name) __gthrw_ ## name
#else
# define __gthrw2(name,name2,type)
# define __gthrw_(name) name
#endif
/* Typically, __gthrw_foo is a weak reference to symbol foo. */
#define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name)
...
#ifdef __GLIBC__
__gthrw2(__gthrw_(__pthread_key_create),
__pthread_key_create,
pthread_key_create)
After preprocessing that expands to:
static __typeof(pthread_key_create) __gthrw___pthread_key_create __attribute__ ((__weakref__("__pthread_key_create")));
It is supposed to be a weak reference to __pthread_key_create, so it should never have a definition, because it is just a reference to glibc's internal __pthread_key_create symbol.
So it looks like something has gone wrong with how you build you library. You should not have an undefined weak symbol.
I recently stumbled into this error, and not because of a missing -pthread.
The situation happened in a somewhat unusual setup: I was compiling a software written in C++14 under Centos7. Since C++14 requires a recent version of GCC, I relied on devtoolset 6 for it.
Given the specific setup, I opened a thread on the Centos mailing list, so I'm directly referencing the relevant thread. See https://lists.centos.org/pipermail/centos-devel/2018-May/016701.html and https://lists.centos.org/pipermail/centos-devel/2018-June/016727.html
In short, it might be caused by some bug in the preprocessor macros, either of glibc or libgcc. It can be fixed by placing #include <thread> in the beginning of the source code which gives problems once compiled. Yes, even if you don't use std::thread in it.
I don't claim this will work for everyone, but it might do the job in some particular situations.
I'm trying to create a shared library from Haskell source code.
I've tried following the instruction here: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell/ but I'm just not having any luck.
When I compile with Haskell 64-bit (ghc 7.0.4 from 2011.4.0.0) I get the following error:
ld: pointer in read-only segment not allowed in slidable image, used in
___gmpn_modexact_1c_odd
As an alternative I also tried the 32-bit version, and depending on the exact flags I use to link get errors such as:
Library not loaded: /usr/local/lib/ghc-7.0.4/base-4.3.1.0/libHSbase-4.3.1.0-ghc7.0.4.dylib
I did manage to get a little further by adding -lHSrts to the linker line. This got me to the point of successfully linking and loading the library, but I'm then unable to find the function name using dlsym (or manually using nm | grep)
Any hints would be greatly appreciated, an example make file, or build line that has successfully built (and used) a shared library on OS X would be appreciated. I'm quite new to Haskell and don't know if I should keep banging my head assuming that the problem is on my end, or for various reasons I shouldn't expect this to work on OS X.
A git repo with all the combinations I've tried is available here: https://github.com/bennoleslie/haskell-shared-example I did manage to get something working for 32-bit ghc, but not 64-bit yet.
It is possible to create working shared libraries on 64-bit OS X, with the latest Haskell Platform release (2012.4 64bit)
The invocation line works for me:
ghc -O2 --make \
-no-hs-main -optl '-shared' -optc '-DMODULE=Test' \
-o libTest.so Test.hs module_init.c
module_init.c should be something like:
#define CAT(a,b) XCAT(a,b)
#define XCAT(a,b) a ## b
#define STR(a) XSTR(a)
#define XSTR(a) #a
#include <HsFFI.h>
extern void CAT(__stginit_, MODULE)(void);
static void library_init(void) __attribute__((constructor));
static void library_init(void)
{
/* This seems to be a no-op, but it makes the GHCRTS envvar work. */
static char *argv[] = { STR(MODULE) ".so", 0 }, **argv_ = argv;
static int argc = 1;
hs_init(&argc, &argv_);
hs_add_root(CAT(__stginit_, MODULE));
}
static void library_exit(void) __attribute__((destructor));
static void library_exit(void)
{
hs_exit();
}
This git repo: https://github.com/bennoleslie/haskell-shared-example contains a working example.
All credit goes to this original source: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell/
You might want to try the ghc port in Homebrew -- https://github.com/mxcl/homebrew/blob/master/Library/Formula/ghc.rb
I want to use the LSM framework with kernel ubuntu 2.6.36.
When I compiled the kernel module, it wrote:
WARNING: "register_security " undefined!
After a lot of googlings, I found the reason is that the register_security() symbol is no longer exported in the 2.6 kernel.
So I added EXPORT_SYMBOL(register_security) in the ../security/security.c file, and recompiled the kernel.
After booting with the new kernel, I added extern int register_security(struct security_operations *ops) in my kernel module file, and compiled the module again.
However, the WARNING information still existed. If I continued to insmode the module, the dmesg told me that
Unknown symbol register_security
What should I do? How can I register a Linux Security Module?
Make sure newly loaded kernel is the one, which is compiled by you.
Check the Licence of your module (Ref: http://lists.jammed.com/linux-security-module/2004/08/0053.html)
In modern kernels register_security symbol does not exported. It means that you can't register LSM module as a module. But if you really wish to do that you can do that :) Look at the exported LSM-symbols like security_sb_copy_data. They are simple wrappers over the security_ops->some_lsm_method. So, you can use their code to determine security_ops pointer value. It needs disassembler though.
Unknown symbol register_security
Happened at the line that you unregister your LSM.
So add unregister_security() in security.c and export it:
/**
* unregister_security - allows security modules to be moved
* #ops : a pointer to the struct security_options that had been registered before.
*/
int unregister_security(struct security_operations *ops)
{
if (ops != security_ops)
{
printk (KERN_INFO "%s: trying to unregister "
"a security_opts structure that is not "
"registered, failing.\n", __FUNCTION__);
return -EINVAL;
}
security_ops = &dummy_security_ops;
return 0;
}
EXPORT_SYMBOL(unregister_security);
And recompiled the kernel.