will this work?

QNX Newsgroups (Archives) qdn.public.qnxrtp.devtools
1
  1. question one:

the following stuff appears a lot in the mozilla build process.
will it work?

*.o files are compiled with -fPIC and then combined into .a file
using “ar cr file.a *.o”.
(is this file.a a shared or static object?).

some new *.o files are compiled with -fPIC and
file.a is then used in the following way.
gcc -shared … -o newobj.so *.o /lib/file.a
is this allowed?
can “gcc -shared” create a shared object, which links to *.a file (static?)?


2) question two:

*.o files are compiled with -fPIC
can the shared obj be created without “-shared” option?
gcc -Wl,-soname,libmy.so.1 -o libmy.so *.o
I’ve seen this behavior (with -shared when linking) in some places.
is it allowed in qnx?
what are the diferences in libmy.so file, when you use or not use “-shared”?

  1. question three:

can the “-Wl,-rpath,…” be used to generate the shared obj to embbed
the lib search path? is it being honored by the OS? 6.1A? 6.2(bmw)?

  1. question four:

what is the reasoning to link to other libs while generating shared
objs (seen this a lot in mozilla build):
gcc -shared -Wl,-soname,libapp1.so.1 -o libapp1.so *.o -L/other/lib -lapp2 -lapp3 ?

in this example, do app2, app3 have to a shared lib also? or it can be
a static lib? (I tried it on linux, it seems app2/app3 can be a mix of
shared/static libs, but on qnx6, not allowed.

thanks in advance for any clarifications.

Frank

2
  1. question four:

what is the reasoning to link to other libs while generating shared
objs (seen this a lot in mozilla build):
gcc -shared -Wl,-soname,libapp1.so.1 -o libapp1.so
*.o -L/other/lib -lapp2 -lapp3 ?

In this example, you create an explicit dependence between libapp1.so
and libapp2/3. Later, when you will finally link app1 with a main
program, you’ll simply do

$(CC) myMain.c -lapp1 -o myMain

There are a number of reasons to do this. The first being to hide
implementation details from the user. Another reason is portability. On
QNX, libapp1 depends on app2/3 while on another operating system, say
Linux, libapp1 may depend only app2. This way, end users are sheilded
from such implementation details.

3

Bernard Leclerc <whittom-leclerc@sympatico.ca> wrote:

  1. question four:

what is the reasoning to link to other libs while generating shared
objs (seen this a lot in mozilla build):
gcc -shared -Wl,-soname,libapp1.so.1 -o libapp1.so
*.o -L/other/lib -lapp2 -lapp3 ?

In this example, you create an explicit dependence between libapp1.so
and libapp2/3. Later, when you will finally link app1 with a main

is the app2/3 actually combined into libapp1.so? or is it just some
kind of path/dependency info being embedded into libapp1.so?

program, you’ll simply do

$(CC) myMain.c -lapp1 -o myMain

in this case, do I still have to have the app2/app3.so around on
the system? or is libapp1.so already having the app2/app3 built in?

thanks!
frank

There are a number of reasons to do this. The first being to hide
implementation details from the user. Another reason is portability. On
QNX, libapp1 depends on app2/3 while on another operating system, say
Linux, libapp1 may depend only app2. This way, end users are sheilded
from such implementation details.

4

is the app2/3 actually combined into libapp1.so? or is it just some
kind of path/dependency info being embedded into libapp1.so?

No, libapp1.so only contains references to its dependents. Read on
dl_open for details.


in this case, do I still have to have the app2/app3.so around on
the system? or is libapp1.so already having the app2/app3 built in?

Yes, librairies referenced by libapp1.so are searched for when
libapp1.so is loaded. Again, dl_open contains the details.

Good reading Frank.

5

Bernard Leclerc <whittom-leclerc@sympatico.ca> wrote:

is the app2/3 actually combined into libapp1.so? or is it just some
kind of path/dependency info being embedded into libapp1.so?

No, libapp1.so only contains references to its dependents. Read on
dl_open for details.

I guess you meant dlopen ?
if that’s the case, it sounds like both libapp2 and libapp3 have
to be shared libs, right? but, as I mentioned in the original post,
question 4, I’ve seen cases in other unix
(bsd, linux, solaris, hpux, aix, etc) that static lib can be
used in (eg, libapp2 is shared, libapp3 is static/archived lib):
gcc -shared -Wl,-soname,libapp1.so.1 -o libapp1.so *.o -L/other/lib -lapp2 -lapp3
you can see lots of those in mozilla builds.
is this not allowed in qnx? or maybe it is a qnx bug?

btw, any thoughts on my other questions?

thanks!

Frank

in this case, do I still have to have the app2/app3.so around on
the system? or is libapp1.so already having the app2/app3 built in?

Yes, librairies referenced by libapp1.so are searched for when
libapp1.so is loaded. Again, dl_open contains the details.

Good reading Frank.

6

fliu@bb.vipstage.com wrote:

Bernard Leclerc <> whittom-leclerc@sympatico.ca> > wrote:
is the app2/3 actually combined into libapp1.so? or is it just some
kind of path/dependency info being embedded into libapp1.so?

No, libapp1.so only contains references to its dependents. Read on
dl_open for details.

I guess you meant dlopen ?
if that’s the case, it sounds like both libapp2 and libapp3 have
to be shared libs, right? but, as I mentioned in the original post,
question 4, I’ve seen cases in other unix
(bsd, linux, solaris, hpux, aix, etc) that static lib can be
used in (eg, libapp2 is shared, libapp3 is static/archived lib):
gcc -shared -Wl,-soname,libapp1.so.1 -o libapp1.so *.o -L/other/lib -lapp2 -lapp3
you can see lots of those in mozilla builds.
is this not allowed in qnx? or maybe it is a qnx bug?

based on this post from gary@gnu.org, it is possible to add
static lib to a shared lib:
http://sources.redhat.com/ml/automake/2001-09/msg00023.html
any comments from qssl?

frank

7

You there, Colin?
Frank

fliu@bb.vipstage.com wrote:

  1. question one:

the following stuff appears a lot in the mozilla build process.
will it work?

*.o files are compiled with -fPIC and then combined into .a file
using “ar cr file.a *.o”.
(is this file.a a shared or static object?).

some new *.o files are compiled with -fPIC and
file.a is then used in the following way.
gcc -shared … -o newobj.so *.o /lib/file.a
is this allowed?
can “gcc -shared” create a shared object, which links to *.a file (static?)?



2) question two:

*.o files are compiled with -fPIC
can the shared obj be created without “-shared” option?
gcc -Wl,-soname,libmy.so.1 -o libmy.so *.o
I’ve seen this behavior (with -shared when linking) in some places.
is it allowed in qnx?
what are the diferences in libmy.so file, when you use or not use “-shared”?

  1. question three:

can the “-Wl,-rpath,…” be used to generate the shared obj to embbed
the lib search path? is it being honored by the OS? 6.1A? 6.2(bmw)?

  1. question four:

what is the reasoning to link to other libs while generating shared
objs (seen this a lot in mozilla build):
gcc -shared -Wl,-soname,libapp1.so.1 -o libapp1.so *.o -L/other/lib -lapp2 -lapp3 ?

in this example, do app2, app3 have to a shared lib also? or it can be
a static lib? (I tried it on linux, it seems app2/app3 can be a mix of
shared/static libs, but on qnx6, not allowed.

thanks in advance for any clarifications.

Frank

8

fliu@bb.vipstage.com wrote:

You there, Colin?
Frank

Yeah, yeah, I was just letting others have a little fun! ;v)

fliu@bb.vipstage.com > wrote:

  1. question one:

the following stuff appears a lot in the mozilla build process.
will it work?

*.o files are compiled with -fPIC and then combined into .a file
using “ar cr file.a *.o”.
(is this file.a a shared or static object?).

Heh, this is an static archive of PIC object files.

some new *.o files are compiled with -fPIC and
file.a is then used in the following way.
gcc -shared … -o newobj.so *.o /lib/file.a
is this allowed?
can “gcc -shared” create a shared object, which links to *.a file (static?)?

Yes. As far as gcc is concerned, a .a is just a collection of .o’s, and
as long as they were compiled PIC, then that’s good.

  1. question two:

*.o files are compiled with -fPIC
can the shared obj be created without “-shared” option?
gcc -Wl,-soname,libmy.so.1 -o libmy.so *.o
I’ve seen this behavior (with -shared when linking) in some places.
is it allowed in qnx?
what are the diferences in libmy.so file, when you use or not use “-shared”?

I don’t expect this would work - without the -shared you are creating an executable,
rather than a shared object.

What is similar is something like this…

gcc -fPIC -c object1.o
gcc -fPIC -c object2.o
gcc -r -o objects.o object1.o object2.o

This will do an incomplete link - it will resolve dependencies etc but
will not do the final relocation.

  1. question three:

can the “-Wl,-rpath,…” be used to generate the shared obj to embbed
the lib search path? is it being honored by the OS? 6.1A? 6.2(bmw)?

Not in 6.1 - this was fixed for 6.2 (although there are still some
bugs - see Igor’s post)

  1. question four:

what is the reasoning to link to other libs while generating shared
objs (seen this a lot in mozilla build):
gcc -shared -Wl,-soname,libapp1.so.1 -o libapp1.so *.o -L/other/lib -lapp2 -lapp3 ?

in this example, do app2, app3 have to a shared lib also? or it can be
a static lib? (I tried it on linux, it seems app2/app3 can be a mix of
shared/static libs, but on qnx6, not allowed.

I think it’s mostly for organisational purposes. I guess libapp1.so needs
symbols in libapp2.so and libapp3.so

As long as they were compiled PIC, then it doesn’t matter if they
are shared objects or static archives.

–
cburgess@qnx.com

9

Colin Burgess <cburgess@qnx.com> wrote:

Yeah, yeah, I was just letting others have a little fun! ;v)

apparently they are too difficult for others :slight_smile:
we need our master Colin!

some new *.o files are compiled with -fPIC and
file.a is then used in the following way.
gcc -shared … -o newobj.so *.o /lib/file.a
is this allowed?
can “gcc -shared” create a shared object, which links to *.a file (static?)?

Yes. As far as gcc is concerned, a .a is just a collection of .o’s, and
as long as they were compiled PIC, then that’s good.

can this /lib/file.a be used to generate executables then?
gcc -o mytest *.o … /lib/file.a
or can it only be used to generate another shared obj?
gcc -shared … -o newobj.so *.so /lib/file.a

what is the reasoning to link to other libs while generating shared
objs (seen this a lot in mozilla build):
gcc -shared -Wl,-soname,libapp1.so.1 -o libapp1.so *.o -L/other/lib -lapp2 -lapp3 ?

in this example, do app2, app3 have to a shared lib also? or it can be
a static lib? (I tried it on linux, it seems app2/app3 can be a mix of
shared/static libs, but on qnx6, not allowed.

I think it’s mostly for organisational purposes. I guess libapp1.so needs
symbols in libapp2.so and libapp3.so

As long as they were compiled PIC, then it doesn’t matter if they
are shared objects or static archives.

if they were all compiled with PIC, it is understandable, as you explained
earlier. but in my case, I’ve seen libapp3.a is actually a static archived
lib (no PIC for those *.o in it). so we have libapp1.so, depending on
libapp2.so and libapp3.a. an application linked with libapp1.so
immediately seg faults on qnx, but runs fine on linux or other unix.
i’ve seen this in the builds of other big applications.
any thoughts?

thanks!
frank

10

fliu@bb.vipstage.com wrote:

Colin Burgess <> cburgess@qnx.com> > wrote:
Yeah, yeah, I was just letting others have a little fun! ;v)

apparently they are too difficult for others > :slight_smile:
we need our master Colin!

Flattery will get you everywhere… :v)


can this /lib/file.a be used to generate executables then?
gcc -o mytest *.o … /lib/file.a
or can it only be used to generate another shared obj?
gcc -shared … -o newobj.so *.so /lib/file.a

Yeah, it can. You have pic code where you don’t really need it,
but that’s not really a problem.

if they were all compiled with PIC, it is understandable, as you explained
earlier. but in my case, I’ve seen libapp3.a is actually a static archived
lib (no PIC for those *.o in it). so we have libapp1.so, depending on
libapp2.so and libapp3.a. an application linked with libapp1.so
immediately seg faults on qnx, but runs fine on linux or other unix.
i’ve seen this in the builds of other big applications.
any thoughts?

Well, other unices have COW (Copy on Write) VM systems, which we don’t have.
So when they get a fault for writing to a shared page (the code of the
lib) then they just make a new page for that app and copy it before the
write.

QNX 6 can’t handle this, hence the straight sigsegv.

–
cburgess@qnx.com

11

Colin Burgess <cburgess@qnx.com> wrote:

can this /lib/file.a be used to generate executables then?
gcc -o mytest *.o … /lib/file.a
or can it only be used to generate another shared obj?
gcc -shared … -o newobj.so *.so /lib/file.a

Yeah, it can. You have pic code where you don’t really need it,
but that’s not really a problem.

“Yeah” means both above will work?
I don’t quite understand the above case one. Is gcc going to treat
file.a as a library and only links in the necessary object files?
or is it just link them all together? Is it a problem to mix
PIC and non-PIC codes? (assuming file.a is ar’ed from all the pic’ed
objects, but the *.o on the command line are normal non-PIC objects).

if they were all compiled with PIC, it is understandable, as you explained
earlier. but in my case, I’ve seen libapp3.a is actually a static archived
lib (no PIC for those *.o in it). so we have libapp1.so, depending on
libapp2.so and libapp3.a. an application linked with libapp1.so
immediately seg faults on qnx, but runs fine on linux or other unix.
i’ve seen this in the builds of other big applications.
any thoughts?

Well, other unices have COW (Copy on Write) VM systems, which we don’t have.
So when they get a fault for writing to a shared page (the code of the
lib) then they just make a new page for that app and copy it before the
write.

So you are saying it will just run on other unices, but the QNX, by
its design, will seg faults ?
Will there be a chance that QNX will work in the future, for this?
Or will it never work because of the design philosophy of QNX is
different?

Thanks Colin, you’da man!

Frank

QNX 6 can’t handle this, hence the straight sigsegv.

–
cburgess@qnx.com

12

fliu@bb.vipstage.com wrote:

“Yeah” means both above will work?
I don’t quite understand the above case one. Is gcc going to treat
file.a as a library and only links in the necessary object files?
or is it just link them all together? Is it a problem to mix
PIC and non-PIC codes? (assuming file.a is ar’ed from all the pic’ed
objects, but the *.o on the command line are normal non-PIC objects).

It will treat it as a normal .a archive, and extra needed object files.
There isn’t a probably with mixing pic and non-pic.

So you are saying it will just run on other unices, but the QNX, by
its design, will seg faults ?
Will there be a chance that QNX will work in the future, for this?
Or will it never work because of the design philosophy of QNX is
different?

Maybe, maybe not… :v)

I doubt that COW will be implemented in the near future, but some
other solutions may be dreamed up…

–
cburgess@qnx.com

13

Colin Burgess <cburgess@qnx.com> wrote:

fliu@bb.vipstage.com > wrote:
“Yeah” means both above will work?
I don’t quite understand the above case one. Is gcc going to treat
file.a as a library and only links in the necessary object files?
or is it just link them all together? Is it a problem to mix
PIC and non-PIC codes? (assuming file.a is ar’ed from all the pic’ed
objects, but the *.o on the command line are normal non-PIC objects).

It will treat it as a normal .a archive, and extra needed object files.
There isn’t a probably with mixing pic and non-pic.

let’s say file.a has a1.o and b1.o, both of which were compiled pic.
now b1.o and b2.o are compiled without pic.
gcc -o exe b1.o b2.o file.a
let’s say, b1.o and b2.o only have used the functions in a1.o,
is gcc going to link b1.o, b2.o and a1.o together?
or is it going to link them all (b1.o, b2.o, a1.o, a2.o)?
(i guess it is probably former, since you said "as a normal .a archive).

in either case, we will end up with a mix of pic (a1.o, a2.o)
and non-pic code (b1.o, b2.o), right?

So you are saying it will just run on other unices, but the QNX, by
its design, will seg faults ?
Will there be a chance that QNX will work in the future, for this?
Or will it never work because of the design philosophy of QNX is
different?

Maybe, maybe not… :v)

I doubt that COW will be implemented in the near future, but some
other solutions may be dreamed up…

It will definitely be nice to have a solution. It’s a big pain
to port codes from other unices, where they assume this is ok.
since 6.2 is around the corner, my guess is the earliest possibility
(if at all) will be after the release of 6.2, right?

another unrelated question, do you know if someone is working on
a global config file (like /etc/ld.so.conf) for listing directories
of shared libs? you once said you would see what you can do about it.
Can you expect it in 6.2?

Thanks!
Frank

14

<a8gl4b$f8p$1@inn.qnx.com>$B$N5-;v$K$*$$$F(B
fliu@bb.vipstage.com$B$5$s$O=q$-$^$7$?!#(B

I doubt that COW will be implemented in the near future, but some
other solutions may be dreamed up…
It will definitely be nice to have a solution. It’s a big pain
to port codes from other unices, where they assume this is ok.

I don’t think Copy-on-Write is acceptable for QNX;
it’ll make execution time unpredictable (fatal for Realtime OS).

The reason other OS do support CoW is * penalty is acceptable and

  • upward compatibility(?), especially for non-ELF executables.
    In nearly-ideal world CoW don’t have to be supported in other OS too.

But I do wish that QNX ld (that’s GNU ld right?) supports
“ld -z text” or similar in SVR4-ish ld which burps on
mixing non-PIC *.o.

kabe

15

kabe@sra-tohoku.co.jp wrote:

a8gl4b$f8p$> 1@inn.qnx.com> >$B$N5-;v$K$*$$$F(B
fliu@bb.vipstage.com> $B$5$s$O=q$-$^$7$?!#(B

I doubt that COW will be implemented in the near future, but some
other solutions may be dreamed up…
It will definitely be nice to have a solution. It’s a big pain
to port codes from other unices, where they assume this is ok.

I don’t think Copy-on-Write is acceptable for QNX;
it’ll make execution time unpredictable (fatal for Realtime OS).

I was referring to Colin’s comment “some other (non-COW) solutions”.
so don’t worry :slight_smile:

frank

The reason other OS do support CoW is * penalty is acceptable and

  • upward compatibility(?), especially for non-ELF executables.
    In nearly-ideal world CoW don’t have to be supported in other OS too.

But I do wish that QNX ld (that’s GNU ld right?) supports
“ld -z text” or similar in SVR4-ish ld which burps on
mixing non-PIC *.o.

kabe

16

let’s say file.a has a1.o and b1.o, both of which were compiled pic.
^

should that be a2.o?

now b1.o and b2.o are compiled without pic.
gcc -o exe b1.o b2.o file.a
let’s say, b1.o and b2.o only have used the functions in a1.o,
is gcc going to link b1.o, b2.o and a1.o together?
or is it going to link them all (b1.o, b2.o, a1.o, a2.o)?
(i guess it is probably former, since you said "as a normal .a archive).

It should only link in the a1.o object file.

in either case, we will end up with a mix of pic (a1.o, a2.o)
and non-pic code (b1.o, b2.o), right?

Yeah.

It will definitely be nice to have a solution. It’s a big pain
to port codes from other unices, where they assume this is ok.
since 6.2 is around the corner, my guess is the earliest possibility
(if at all) will be after the release of 6.2, right?

Definately not 6.2, and I wouldn’t hold your breathe on this one! :v)

another unrelated question, do you know if someone is working on
a global config file (like /etc/ld.so.conf) for listing directories
of shared libs? you once said you would see what you can do about it.
Can you expect it in 6.2?

Not 6.2, sorry.

–
cburgess@qnx.com