Re: Need help building & integrating library into target program

Re: Need help building & integrating library into target program

[Stuart Summerville (Deimus)]

(Sorry for the repost - resent to maintain thread)

>It would be best to show us how you're trying to link against the
>library; knowing your platform would also be helpful.
>--ag
>

Hi Arthur,

Given that I have mylib.a in the current directory, I issue the command:

gcc -static -g -o rw startup_lib.a

to produce the rw executable. Then, issuing the command:

ldd rw

tells me that this dynamically linked executable is dependent on mylib.o. I
presume that as its linked statically, there shouldn't be any lib
dependence....

Tools used:
Solaris 2.5.1
gcc egcs-2.91.57 19980901 (egcs-1.1 release)
ld 2.8.1 (with BFD 2.8.1)

Also, mylib.a was created in the following manner:

gcc -MD -I../include -g -o init.o -c init.c
ar rv ../../../obj/mylib.a *.o

I've seen the same behaviour on two Sol251 boxes.

To contrast this, if I do the same thing on a Redhat Linux (5.2) box (gcc =
2.7.2.3, ld = 2.9.1 (with BFD 2.9.1.0.15)), it works fine. If statically
linked, ldd won't touch it (unlike the Solaris box, which still shows that
erroneous dependence) & it runs properly; if dynamically linked, ldd reports
that libc and ld-linux are linked but no mylib.a (or even mylib.o).

?

Some other questions:

1) does linking of libraries dynamically only affect files specified with
the -l switch to ld? Can a file specified as an ordinary object file to ld,
be dynamically linked in? eg. if I don't supply ld with the -static switch,
will archive files passed in the manner "ld -o myprog mylib.a ..." be
statically linked anyway?
2) Is there any use in my creating arcive/object files with the -shared
switch to ld? This seems to be a useful thing to do, but the ld manpage
suggests its not a common method anymore.

Thanks,

sTu.

----------------------------------------------
Stuart Summerville
Home: stus@deimus.com.au
Work: stuart.summerville@icpdd.neca.nec.com.au
----------------------------------------------

Re: Need help building & integrating library into target program

[Stuart Summerville (Deimus)]

(Sorry for the repost - resent to maintain thread)

>It would be best to show us how you're trying to link against the
>library; knowing your platform would also be helpful.
>--ag
>

Hi Arthur,

Given that I have mylib.a in the current directory, I issue the command:

gcc -static -g -o rw startup_lib.a

to produce the rw executable. Then, issuing the command:

ldd rw

tells me that this dynamically linked executable is dependent on mylib.o. I
presume that as its linked statically, there shouldn't be any lib
dependence....

Tools used:
Solaris 2.5.1
gcc egcs-2.91.57 19980901 (egcs-1.1 release)
ld 2.8.1 (with BFD 2.8.1)

Also, mylib.a was created in the following manner:

gcc -MD -I../include -g -o init.o -c init.c
ar rv ../../../obj/mylib.a *.o

I've seen the same behaviour on two Sol251 boxes.

To contrast this, if I do the same thing on a Redhat Linux (5.2) box (gcc =
2.7.2.3, ld = 2.9.1 (with BFD 2.9.1.0.15)), it works fine. If statically
linked, ldd won't touch it (unlike the Solaris box, which still shows that
erroneous dependence) & it runs properly; if dynamically linked, ldd reports
that libc and ld-linux are linked but no mylib.a (or even mylib.o).

?

Some other questions:

1) does linking of libraries dynamically only affect files specified with
the -l switch to ld? Can a file specified as an ordinary object file to ld,
be dynamically linked in? eg. if I don't supply ld with the -static switch,
will archive files passed in the manner "ld -o myprog mylib.a ..." be
statically linked anyway?
2) Is there any use in my creating arcive/object files with the -shared
switch to ld? This seems to be a useful thing to do, but the ld manpage
suggests its not a common method anymore.

Thanks,

sTu.

----------------------------------------------
Stuart Summerville
Home: stus@deimus.com.au
Work: stuart.summerville@icpdd.neca.nec.com.au
----------------------------------------------

Re: Need help building & integrating library into target program

[Stuart Summerville]

hmmm, well, after all that, the problem seems to have resolved itself. I took
the source tree home & the whole thing worked fine (on a Linux box). Reworked
the make system & brought it back to work today, to find that it now also works
properly at work (on the Solaris box)!

Not much of a problem resolution strategy..... eh??

Thanks anyway.

sTu.
________________________________________________________________________
Stuart Summerville                     NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                  Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                  649-655 Springvale Road Mulgrave
stuarts@<nospam>icpdd.neca.nec.com.au  VIC 3170, AUSTRALIA

Need help building & integrating library into target program

[Stuart Summerville]

Hi all,

I'm trying to build a custom library that is then integrated into other target
programs. I'm having problems linking the library into the final executable.

Here's the steps I've taken:
1) Compile to object file (using -c switch on gcc) each of the source files for
the library.
2) Archive the object files together in mylib.a. This is using 'ar rv mylib.a
*.o'.
3) Compile another source file (new_app.c) ready to use the library. Same
compilation as before, to an object file.
4) Link new_app.o with mylib.a, using gcc. I've tried passing in the -static
switch also. The output is new_app, which should also contains any required
functions from mylib.

All goes well until runtime, when ld.so.1 informs me that it couldn't open
mylib.o (as opposed to mylib.a) & that new_app has been killed.

Why is this happening? Where is it getting mylib.o from?

Another makefile I have aquired, that I've based my makefile on, takes one extra
step after creating mylib.a. It runs the following:

prompt> : mylib.a

This seems to fuction properly,and does change the file, somehow. The variable
used to hold this ':' keyword is called $(RANLIB) which suggests its generating
an index into mylib.a, but I'm not sure how this mapping (of ':' to ranlib or
'ar -s') is done, unless its prodding the make program to do so, somehow.

So far as I can tell, my makefile is manipulating the library file just as the
sample one is.

If necessary, can you suggest some methods of analysing mylib.a to look for
problems?

Thanks for any help,

sTu.


________________________________________________________________________
Stuart Summerville                     NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                  Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                  649-655 Springvale Road Mulgrave
stuarts@<nospam>icpdd.neca.nec.com.au  VIC 3170, AUSTRALIA

Re: Need help building & integrating library into target program

[Arthur Gold]

Stuart Summerville wrote:
> 
> Hi all,
> 
> I'm trying to build a custom library that is then integrated into other target
> programs. I'm having problems linking the library into the final executable.
> 
> Here's the steps I've taken:
> 1) Compile to object file (using -c switch on gcc) each of the source files for
> the library.
> 2) Archive the object files together in mylib.a. This is using 'ar rv mylib.a
> *.o'.
> 3) Compile another source file (new_app.c) ready to use the library. Same
> compilation as before, to an object file.
> 4) Link new_app.o with mylib.a, using gcc. I've tried passing in the -static
> switch also. The output is new_app, which should also contains any required
> functions from mylib.
> 
> All goes well until runtime, when ld.so.1 informs me that it couldn't open
> mylib.o (as opposed to mylib.a) & that new_app has been killed.
> 
> Why is this happening? Where is it getting mylib.o from?
> 
> Another makefile I have aquired, that I've based my makefile on, takes one extra
> step after creating mylib.a. It runs the following:
> 
> prompt> : mylib.a
> 
> This seems to fuction properly,and does change the file, somehow. The variable
> used to hold this ':' keyword is called $(RANLIB) which suggests its generating
> an index into mylib.a, but I'm not sure how this mapping (of ':' to ranlib or
> 'ar -s') is done, unless its prodding the make program to do so, somehow.
> 
> So far as I can tell, my makefile is manipulating the library file just as the
> sample one is.
> 
> If necessary, can you suggest some methods of analysing mylib.a to look for
> problems?
> 
> Thanks for any help,
> 
> sTu.
It would be best to show us how you're trying to link against the
library; knowing your platform would also be helpful.
--ag
> 
> ________________________________________________________________________
> Stuart Summerville                     NEC Australia Pty. Ltd.
> ph: (+61 3) 9264-3090                  Integrated Comm Products (R&D)
> fax:(+61 3) 9264-3841                  649-655 Springvale Road Mulgrave
> stuarts@<nospam>icpdd.neca.nec.com.au  VIC 3170, AUSTRALIA

-- 
Artie Gold, Austin, TX  (finger the cs.utexas.edu account for more info)
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
A: Look for a lawyer who speaks Aramaic...about trademark infringement.

Re: Need help building & integrating library into target program

[Stuart Summerville (NEC)]

>It would be best to show us how you're trying to link against the
>library; knowing your platform would also be helpful.
>--ag
>

Hi Arthur,

Given that I have mylib.a in the current directory, I issue the command:

gcc -static -g -o rw startup_lib.a

to produce the rw executable. Then, issuing the command:

ldd rw

tells me that this dynamically linked executable is dependent on mylib.o. I
presume that as its linked statically, there shouldn't be any lib
dependence....

Tools used:
Solaris 2.5.1
gcc egcs-2.91.57 19980901 (egcs-1.1 release)
ld 2.8.1 (with BFD 2.8.1)

Also, mylib.a was created in the following manner:

gcc -MD -I../include -g -o init.o -c init.c
ar rv ../../../obj/mylib.a *.o

I've seen the same behaviour on two Sol251 boxes.

To contrast this, if I do the same thing on a Redhat Linux (5.2) box (gcc =
2.7.2.3, ld = 2.9.1 (with BFD 2.9.1.0.15)), it works fine. If statically
linked, ldd won't touch it (unlike the Solaris box, which still shows that
erroneous dependence) & it runs properly; if dynamically linked, ldd reports
that libc and ld-linux are linked but no mylib.a (or even mylib.o).

?

Some other questions:

1) does linking of libraries dynamically only affect files specified with
the -l switch to ld? Can a file specified as an ordinary object file to ld,
be dynamically linked in? eg. if I don't supply ld with the -static switch,
will archive files passed in the manner "ld -o myprog mylib.a ..." be
statically linked anyway?
2) Is there any use in my creating arcive/object files with the -shared
switch to ld? This seems to be a useful thing to do, but the ld manpage
suggests its not a common method anymore.

Thanks,

sTu.

_________________________________________________________________________
Stuart Summerville                         NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                      Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                      649-655 Springvale Road
e-mail: stuarts@icpdd.neca.nec.com.au      Mulgrave, VIC 3170, AUSTRALIA

Re: Need help building & integrating library into target program

[Stuart Summerville]

(More apologies for re-posts - seemingly posting to the mailing list ain't the
same as posting to the usenet newsgroup...)


>It would be best to show us how you're trying to link against the
>library; knowing your platform would also be helpful.
>--ag
>

Hi Arthur,

Given that I have mylib.a in the current directory, I issue the command:

gcc -static -g -o rw startup_lib.a

to produce the rw executable. Then, issuing the command:

ldd rw

tells me that this dynamically linked executable is dependent on mylib.o. I
presume that as its linked statically, there shouldn't be any lib dependence....

Tools used:
Solaris 2.5.1
gcc egcs-2.91.57 19980901 (egcs-1.1 release)
ld 2.8.1 (with BFD 2.8.1)

Also, mylib.a was created in the following manner:

gcc -MD -I../include -g -o init.o -c init.c
ar rv ../../../obj/mylib.a *.o

I've seen the same behaviour on two Sol251 boxes.

To contrast this, if I do the same thing on a Redhat Linux (5.2) box (gcc =
2.7.2.3, ld = 2.9.1 (with BFD 2.9.1.0.15)), it works fine. If statically linked,
ldd won't touch it (unlike the Solaris box, which still shows that erroneous
dependence) & it runs properly; if dynamically linked, ldd reports that libc and
ld-linux are linked but no mylib.a (or even mylib.o).

?

Some other questions:

1) does linking of libraries dynamically only affect files specified with the -l
switch to ld? Can a file specified as an ordinary object file to ld, be
dynamically linked in? eg. if I don't supply ld with the -static switch, will
archive files passed in the manner "ld -o myprog mylib.a ..." be statically
linked anyway?
2) Is there any use in my creating arcive/object files with the -shared switch
to ld? This seems to be a useful thing to do, but the ld manpage suggests its
not a common method anymore.

Thanks,

sTu.

_________________________________________________________________________
Stuart Summerville                         NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                      Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                      649-655 Springvale Road
e-mail: stuarts@icpdd.neca.nec.com.au      Mulgrave, VIC 3170, AUSTRALIA  
________________________________________________________________________
Stuart Summerville                     NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                  Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                  649-655 Springvale Road Mulgrave
stuarts@<nospam>icpdd.neca.nec.com.au  VIC 3170, AUSTRALIA

Re: Need help building & integrating library into target program

[Stuart Summerville]

hmmm, well, after all that, the problem seems to have resolved itself. I took
the source tree home & the whole thing worked fine (on a Linux box). Reworked
the make system & brought it back to work today, to find that it now also works
properly at work (on the Solaris box)!

Not much of a problem resolution strategy..... eh??

Thanks anyway.

sTu.
________________________________________________________________________
Stuart Summerville                     NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                  Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                  649-655 Springvale Road Mulgrave
stuarts@<nospam>icpdd.neca.nec.com.au  VIC 3170, AUSTRALIA

Re: Need help building & integrating library into target program

[Stuart Summerville]

(More apologies for re-posts - seemingly posting to the mailing list ain't the
same as posting to the usenet newsgroup...)


>It would be best to show us how you're trying to link against the
>library; knowing your platform would also be helpful.
>--ag
>

Hi Arthur,

Given that I have mylib.a in the current directory, I issue the command:

gcc -static -g -o rw startup_lib.a

to produce the rw executable. Then, issuing the command:

ldd rw

tells me that this dynamically linked executable is dependent on mylib.o. I
presume that as its linked statically, there shouldn't be any lib dependence....

Tools used:
Solaris 2.5.1
gcc egcs-2.91.57 19980901 (egcs-1.1 release)
ld 2.8.1 (with BFD 2.8.1)

Also, mylib.a was created in the following manner:

gcc -MD -I../include -g -o init.o -c init.c
ar rv ../../../obj/mylib.a *.o

I've seen the same behaviour on two Sol251 boxes.

To contrast this, if I do the same thing on a Redhat Linux (5.2) box (gcc =
2.7.2.3, ld = 2.9.1 (with BFD 2.9.1.0.15)), it works fine. If statically linked,
ldd won't touch it (unlike the Solaris box, which still shows that erroneous
dependence) & it runs properly; if dynamically linked, ldd reports that libc and
ld-linux are linked but no mylib.a (or even mylib.o).

?

Some other questions:

1) does linking of libraries dynamically only affect files specified with the -l
switch to ld? Can a file specified as an ordinary object file to ld, be
dynamically linked in? eg. if I don't supply ld with the -static switch, will
archive files passed in the manner "ld -o myprog mylib.a ..." be statically
linked anyway?
2) Is there any use in my creating arcive/object files with the -shared switch
to ld? This seems to be a useful thing to do, but the ld manpage suggests its
not a common method anymore.

Thanks,

sTu.

_________________________________________________________________________
Stuart Summerville                         NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                      Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                      649-655 Springvale Road
e-mail: stuarts@icpdd.neca.nec.com.au      Mulgrave, VIC 3170, AUSTRALIA  
________________________________________________________________________
Stuart Summerville                     NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                  Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                  649-655 Springvale Road Mulgrave
stuarts@<nospam>icpdd.neca.nec.com.au  VIC 3170, AUSTRALIA

Re: Need help building & integrating library into target program

[Stuart Summerville (NEC)]

>It would be best to show us how you're trying to link against the
>library; knowing your platform would also be helpful.
>--ag
>

Hi Arthur,

Given that I have mylib.a in the current directory, I issue the command:

gcc -static -g -o rw startup_lib.a

to produce the rw executable. Then, issuing the command:

ldd rw

tells me that this dynamically linked executable is dependent on mylib.o. I
presume that as its linked statically, there shouldn't be any lib
dependence....

Tools used:
Solaris 2.5.1
gcc egcs-2.91.57 19980901 (egcs-1.1 release)
ld 2.8.1 (with BFD 2.8.1)

Also, mylib.a was created in the following manner:

gcc -MD -I../include -g -o init.o -c init.c
ar rv ../../../obj/mylib.a *.o

I've seen the same behaviour on two Sol251 boxes.

To contrast this, if I do the same thing on a Redhat Linux (5.2) box (gcc =
2.7.2.3, ld = 2.9.1 (with BFD 2.9.1.0.15)), it works fine. If statically
linked, ldd won't touch it (unlike the Solaris box, which still shows that
erroneous dependence) & it runs properly; if dynamically linked, ldd reports
that libc and ld-linux are linked but no mylib.a (or even mylib.o).

?

Some other questions:

1) does linking of libraries dynamically only affect files specified with
the -l switch to ld? Can a file specified as an ordinary object file to ld,
be dynamically linked in? eg. if I don't supply ld with the -static switch,
will archive files passed in the manner "ld -o myprog mylib.a ..." be
statically linked anyway?
2) Is there any use in my creating arcive/object files with the -shared
switch to ld? This seems to be a useful thing to do, but the ld manpage
suggests its not a common method anymore.

Thanks,

sTu.

_________________________________________________________________________
Stuart Summerville                         NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                      Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                      649-655 Springvale Road
e-mail: stuarts@icpdd.neca.nec.com.au      Mulgrave, VIC 3170, AUSTRALIA

Re: Need help building & integrating library into target program

[Arthur Gold]

Stuart Summerville wrote:
> 
> Hi all,
> 
> I'm trying to build a custom library that is then integrated into other target
> programs. I'm having problems linking the library into the final executable.
> 
> Here's the steps I've taken:
> 1) Compile to object file (using -c switch on gcc) each of the source files for
> the library.
> 2) Archive the object files together in mylib.a. This is using 'ar rv mylib.a
> *.o'.
> 3) Compile another source file (new_app.c) ready to use the library. Same
> compilation as before, to an object file.
> 4) Link new_app.o with mylib.a, using gcc. I've tried passing in the -static
> switch also. The output is new_app, which should also contains any required
> functions from mylib.
> 
> All goes well until runtime, when ld.so.1 informs me that it couldn't open
> mylib.o (as opposed to mylib.a) & that new_app has been killed.
> 
> Why is this happening? Where is it getting mylib.o from?
> 
> Another makefile I have aquired, that I've based my makefile on, takes one extra
> step after creating mylib.a. It runs the following:
> 
> prompt> : mylib.a
> 
> This seems to fuction properly,and does change the file, somehow. The variable
> used to hold this ':' keyword is called $(RANLIB) which suggests its generating
> an index into mylib.a, but I'm not sure how this mapping (of ':' to ranlib or
> 'ar -s') is done, unless its prodding the make program to do so, somehow.
> 
> So far as I can tell, my makefile is manipulating the library file just as the
> sample one is.
> 
> If necessary, can you suggest some methods of analysing mylib.a to look for
> problems?
> 
> Thanks for any help,
> 
> sTu.
It would be best to show us how you're trying to link against the
library; knowing your platform would also be helpful.
--ag
> 
> ________________________________________________________________________
> Stuart Summerville                     NEC Australia Pty. Ltd.
> ph: (+61 3) 9264-3090                  Integrated Comm Products (R&D)
> fax:(+61 3) 9264-3841                  649-655 Springvale Road Mulgrave
> stuarts@<nospam>icpdd.neca.nec.com.au  VIC 3170, AUSTRALIA

-- 
Artie Gold, Austin, TX  (finger the cs.utexas.edu account for more info)
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
A: Look for a lawyer who speaks Aramaic...about trademark infringement.

Need help building & integrating library into target program

[Stuart Summerville]

Hi all,

I'm trying to build a custom library that is then integrated into other target
programs. I'm having problems linking the library into the final executable.

Here's the steps I've taken:
1) Compile to object file (using -c switch on gcc) each of the source files for
the library.
2) Archive the object files together in mylib.a. This is using 'ar rv mylib.a
*.o'.
3) Compile another source file (new_app.c) ready to use the library. Same
compilation as before, to an object file.
4) Link new_app.o with mylib.a, using gcc. I've tried passing in the -static
switch also. The output is new_app, which should also contains any required
functions from mylib.

All goes well until runtime, when ld.so.1 informs me that it couldn't open
mylib.o (as opposed to mylib.a) & that new_app has been killed.

Why is this happening? Where is it getting mylib.o from?

Another makefile I have aquired, that I've based my makefile on, takes one extra
step after creating mylib.a. It runs the following:

prompt> : mylib.a

This seems to fuction properly,and does change the file, somehow. The variable
used to hold this ':' keyword is called $(RANLIB) which suggests its generating
an index into mylib.a, but I'm not sure how this mapping (of ':' to ranlib or
'ar -s') is done, unless its prodding the make program to do so, somehow.

So far as I can tell, my makefile is manipulating the library file just as the
sample one is.

If necessary, can you suggest some methods of analysing mylib.a to look for
problems?

Thanks for any help,

sTu.


________________________________________________________________________
Stuart Summerville                     NEC Australia Pty. Ltd.
ph: (+61 3) 9264-3090                  Integrated Comm Products (R&D)
fax:(+61 3) 9264-3841                  649-655 Springvale Road Mulgrave
stuarts@<nospam>icpdd.neca.nec.com.au  VIC 3170, AUSTRALIA