libc.so1 & libc.so2

I need to build a boot image that supports both libc.so1 & libc.so2. What’s
worse is that I need the libc.so.1 to support a 3rd party flash driver
(devf-gmx from Arcom) so it must be built into the boot image. No matter
what I try to do, something compleins that it can’t find a shared library.
I.e. “Can’t start xxxx (83)”

What is the correct way to include both shared libs in the boot image?

How do most utilities know which version they need to link with?

Why is lib.so needed at all?

The last two questions go together. I figure that either a utility knows
which shared lib it needs and doesn’t care about libc.so or it doesn’t know
and can be easily fooled by linking to the wrong version.


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net

Bill Caroselli <qtps@earthlink.net> wrote:

Hello Bill,

I need to build a boot image that supports both libc.so1 & libc.so2. What’s
worse is that I need the libc.so.1 to support a 3rd party flash driver
(devf-gmx from Arcom) so it must be built into the boot image. No matter
what I try to do, something compleins that it can’t find a shared library.
I.e. “Can’t start xxxx (83)”

What does objdump returns (‘objdump -x BINARY | grep NEEDED’)?
Also what you get when you ‘export DL_DEBUG=1’ and you start your
application?
How do you build it? with what options? can you post a small test case?


What is the correct way to include both shared libs in the boot image?

links

[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so.2
[type=link] /usr/lib/ldqnx.so.1=/proc/boot/libc.so.1


libraries

libc.so.2
libc.so.1


How do most utilities know which version they need to link with?

On your host, during linking it uses your *.conf files in your order to determine
what libc to link against. It links against ldqnx.so.2 → libc.so.2 (on 6.1.x) or
ldqnx.so.1 → libc.so.1. (on 6.0.x system).

Regards,

Marcin

Why is lib.so needed at all?

The last two questions go together. I figure that either a utility knows
which shared lib it needs and doesn’t care about libc.so or it doesn’t know
and can be easily fooled by linking to the wrong version.


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net

No. You misunderstood the question. (Took it out of context.)

If libc.so.2 is available, why must there also be a libc.so?

I.E. Is there anything that tries to link to libc.so WITHOUT SPECIFYING THE
…1 OR .2?


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net


“Operating System Tech Support” <os@qnx.com> wrote in message
news:9su2d9$19a$1@nntp.qnx.com

Why is lib.so needed at all?

Unless you staticly link all the C lib functions (ie. strcmp() ) into each
executable that makes these calls, you need the shared lib C. Staticly
linking everyone will make their size quite large and duplicates code that
is common among all execuatables.

-Adam

No. You misunderstood the question. (Took it out of context.)

If libc.so.2 is available, why must there also be a libc.so?

I.E. Is there anything that tries to link to libc.so WITHOUT SPECIFYING THE
.1 OR .2?

Everything since when you build something it links against -lc. This will be
resolved to whatever libc.so is pointing to. On 6.0.x this was libc.so.1
and on 6.1.x it is libc.so.2. Nothing, that I am aware of, will attempt
to load libc.so at runtime. Does that help you?

chris

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

“Chris McKillop” <cdm@qnx.com> wrote in message
news:9su5pb$1j8$3@nntp.qnx.com

Everything since when you build something it links against -lc. This will
be
resolved to whatever libc.so is pointing to. On 6.0.x this was libc.so.1
and on 6.1.x it is libc.so.2. Nothing, that I am aware of, will attempt
to load libc.so at runtime. Does that help you?

Can I assume from that, that nothing will ever look for libc.so by name? If

so, why does the name exist?


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net

Everything since when you build something it links against -lc. This will
be
resolved to whatever libc.so is pointing to. On 6.0.x this was libc.so.1
and on 6.1.x it is libc.so.2. Nothing, that I am aware of, will attempt
to load libc.so at runtime. Does that help you?


Can I assume from that, that nothing will ever look for libc.so by name? If
so, why does the name exist?

Like i said, so when code is being linked into a binary the linker can find
the C library. You generally don’t need a libc.so entry in an embedded boot
image, but since it is just a symlink most people do it for clarity (ie:
what libc is “current” and what one is used for supporting legacy apps).

chris

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Why is lib.so needed at all?

Unless you staticly link all the C lib functions (ie. strcmp() ) into each
executable that makes these calls, you need the shared lib C. Staticly
linking everyone will make their size quite large and duplicates code that
is common among all execuatables.

-Adam