change location of libc.so.6

[jeziorm]

Hello!

I want to execute some test odbc driver but this drive require other
libc.so.6 than that installed on system - /lib64/libc.so.6. What can i
do to create example: /lib64-test copy all libraries to catalog and
execute my odbc driver and system will know that correct libraries
reside on /lib64-test not in /lib64

??

Regards -MJK

[Aragorn]

On Thursday 14 July 2011 08:22 in alt.os.linux, jeziorm enlightened
humanity with the following words...:

Two options...

1) Create a chroot environment with the glibc of your choice; or

2) Set up a virtual machine with VMWare, VirtualBox, Bochs or
something similar. If you have the Containers for Linux package
installed, then you can create something in between a chroot and
a virtual machine, i.e. a userspace container with its own glibc,
user accounts and filesystems, and it's own init as PID 1, but
which runs on top of the same kernel as your main system.

Hope this was useful. ;-)

--
Aragorn
(registered GNU/Linux user #223157)

[Jasen Betts]

On 2011-07-14, jeziorm <a...@aaa.ccc> wrote:
> Hello!
>
> I want to execute some test odbc driver but this drive require other
> libc.so.6 than that installed on system - /lib64/libc.so.6. What can i

possibly use LD_LIBRARY_PATH and/or LD_PRELOAD

read the "ld.so" man page

--
⚂⚃ 100% natural

[unruh]

On 2011-07-14, jeziorm <a...@aaa.ccc> wrote:

LD_LIBRARY_PATH environment variable.

>
> ??
>
> Regards -MJK

[J G Miller]

On Thursday, July 14th, 2011 at 13:59:53h +0000, Unruh suggested:

> LD_LIBRARY_PATH environment variable.

LD_LIBRARY_PATH is ignored when loading a setuid program.

Is it also ignored, as it should be, when root runs a program?

[Richard Kettlewell]

J G Miller <mil...@yoyo.ORG> writes:
> Unruh suggested:

>> LD_LIBRARY_PATH environment variable.
> LD_LIBRARY_PATH is ignored when loading a setuid program.

The test whether the real and effective uids and gids match. A
non-set[ug]id program run in a context where they don't match will
therefore also not honor the 'unsecure' environment variables.

> Is it also ignored, as it should be, when root runs a program?

It isn't and there's no reason it should be.

--
http://www.greenend.org.uk/rjk/

[Eef Hartman]

jeziorm <a...@aaa.ccc> wrote:
> do to create example: /lib64-test copy all libraries to catalog and
> execute my odbc driver and system will know that correct libraries
> reside on /lib64-test not in /lib64

Use (at link time) -L /lib64-test -nodefaultlibs -l libc
to tell the linker to include that directory and NOT to use the
default libs in /lib. It does mean all the default libs (libc,
libm when used, libgcc) will have to explicitly defined on the
commandline (with -l option). See also man gcc at the -nodefaultlibs
cq the nostdlib options.
--
******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-27 82525 **
******************************************************************

[Richard Kettlewell]

Eef Hartman <E.J.M....@tudelft.nl> writes:
> jeziorm <a...@aaa.ccc> wrote:

>> do to create example: /lib64-test copy all libraries to catalog and
>> execute my odbc driver and system will know that correct libraries
>> reside on /lib64-test not in /lib64
>
> Use (at link time) -L /lib64-test -nodefaultlibs -l libc
> to tell the linker to include that directory and NOT to use the
> default libs in /lib. It does mean all the default libs (libc,
> libm when used, libgcc) will have to explicitly defined on the
> commandline (with -l option). See also man gcc at the -nodefaultlibs
> cq the nostdlib options.

I think the point is that the OP has a binary odbc provider that was
built against a later version of glibc than they have installed.

--
http://www.greenend.org.uk/rjk/