Re: How to modify LD_LIBRARY_PATH

[David Smith <dsmith at redhat dot com>]

(2nd try here)

Arkady,

OK, I think I see what you are trying to do here. I think systemtap
does do what you want, just not the way you are trying to do it.

systemtap's notion of cross-compiling isn't true cross-compiling - we
don't do a chroot into some new environment and run with files and
executables in the chroot. systemtap's version of cross-compiling is
more like "hey, I want to be able to compile kernel modules for
kernels released with RHEL 7.2, 7.3, and 7.4". We're still going to
use the system's compiler for all the kernel-development environments
installed. That works great when you are staying within the same
distro. That doesn't work when you are trying to run across distros
(who have different compilers which support different options as
you've discovered). You definitely want to compile a kernel module
with the same compiler that you compiled the kernel with, since you
want structures, etc. to be laid out the same.

(Note that I've never actually worked on this systemtap feature, so
all the above is from memory and recollections and could be completely
wrong. If so, someone will come along and correct me.)

So, how should you be doing this? You'll want to set up a systemtap
compile server - one for each distro. Note that each compile server
system doesn't have to be a real system, it could be a virtual
machine. In the background, the systemtap servers use avahi to
broadcast what kernel versions they support. When the '--use-sever'
option is used with the systemtap client, the client looks for a match
to the system it is compiling for and ships the script off to the
appropriate systemtap compile server and then the module gets
transparently shipped back to the client. From the client's point of
view, nothing changes except for adding in the '--use-server' option.

I believe that using the compile server will solve your problem.

On Tue, Mar 14, 2017 at 7:12 AM, Arkady <arkady.miasnikov.ca@gmail.com> wrote:
> Hi,
>
> My goal is to create a build environment for the kernel modules which
> target different kernels in the different distros - Ubuntu, CentOS,
> etc.
>
> I am trying to build the kernel modules in a chroot environment based
> on CentOS6. The approach works fine for CentOS kernels.
> When I am trying to compile a module for the Ubuntu kernel
> 3.8.0-31-generic all build commands similar to this one fail:
>
> env -uARCH -uKBUILD_EXTMOD -uCROSS_COMPILE -uKBUILD_IMAGE
> -uKCONFIG_CONFIG -uINSTALL_PATH -uLD_LIBRARY_PATH
> PATH=/usr/bin:/bin:/opt/rh/python27/root/usr/bin:/opt/rh/devtoolset-4/root/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> make -C //lib/modules/3.8.0-31-generic/build
> M=/tmp/stap5IyPLq/typequery_kmod_23 modules CONFIG_DE>
>
> /usr/src/linux-headers-3.8.0-31-generic/arch/x86/Makefile:103:
> CONFIG_X86_X32 enabled but no binutils support
>   Building modules, stage 2.
>   MODPOST 1 modules
> scripts/mod/modpost: /lib64/libc.so.6: version `GLIBC_2.14' not found
> (required by scripts/mod/modpost)
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> I have GLIBC=2.14 installed in /opt/glibc-2.14/lib
>
> In the function
> make_any_make_cmd() I see "Sanitize environment variables for kbuild
> invocation" and explicit undef for LD_LIBRARY_PATH
> How can I modify LD_LIBRARY_PATH anyway?
>
> Thank you, Arkady.



-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)