Re: How to modify LD_LIBRARY_PATH

[Arkady <arkady dot miasnikov dot ca at gmail dot com>]

Just to help Google search.

I have solved the problem of cross compilation of the kernel modules
by compiling (almost) natively in Docker containers.

See for details https://github.com/larytet/YALAS/tree/master/docker

Thanks.

On Thu, Mar 16, 2017 at 11:51 PM, David Smith <dsmith@redhat.com> wrote:
> (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)