Re: GCC C/C++ runtime library question

On 14 Oct 2003 23:46:56 -0400 in comp.compilers,
ramanathan.ramadass@spirentcom.com (Ramanathan Ramadass) wrote:


>I am trying to replace the standard C and C++ libraries which comes
>with a Linux distro with our own(licensed from a 3rd party vendor). We
>will be providing the lower level layer which the C/C++ library
>uses(i.e. the system calls). What i would like to do is replace the
>standard and the runtime libraries which come with gcc with our own. I
>am a newbie in this and hence have some basic questions;


Your vendor should be able to provide information about replacing a
compiler specific library with theirs, assuming they don't provide a
compiler, and maybe even if they do. ;^>


>1. What is the exact difference between the C runtime and the C
>standard libraries i.e where does one end and the other begin;
>specifically w.r.t gcc? While i am going through a lot of text(both
>online and book form) i am not 100% clear on this.


If you have gcc installed, 'info gccint' gives you more
information about the compiler collection and its interfaces, and
there are web pages and manuals at http://gcc.gnu.org/onlinedocs
at the bottom under Current Development.
And there really is not a great distinction between C runtime and
standard libraries: the C standard library is a subset of the
POSIX standard library which is a subset of any *IX system's
library. Runtime support may be just another routine in the
library, or maybe flagged as such with an _.


>2. In a gcc distribution where exactly does the compiler specific
>magic lie within the runtime libraries? I might have to modify gcc to
>use only my libraries but where and how do i begin? Currently i have
>built the 3rd party vendor's library and am linking with it but for
>some symbols i still have to go to the gcc runtimes. I am running "nm"
>and extracting the object modules using "ar" for all the unresolved
>symbols; which seems to be a roundabout way of doing things. What i
>would like is to understand the structure of how gcc interfaces with
>its runtimes. Would appreciate any and all help on this. Pointers to
>other articles/links/books will also be very welcome.


If you're lucky, runtime support routines should begin with _.
Substituting standard libraries should only require specifying
the 3rd party header include directory on the compile/cc command
line -Iincdir and their standard library and directory on the
build/ld command line: -Llibdir -lstd.
Alternatively, environment variables CPATH, C_INCLUDE_PATH,
CPLUS_INCLUDE_PATH, and LIBRARY_PATH can be set to provide all
the directories.
The gcc/gpp/g++ driver programs shouldn't be hard to tweak to add
these paths and library, once you get everything working using
options or environment variables.


Getting any gcc helper routines to call your standard library
helper routines requires deleting any routines with the same name
from (a copy of) the gcc libraries glib*, and adding your
standard library both before and after glib* on the build/ld
command line.
Similarly, supplying your own system call interface routines
requires deleting any routines with the same name from glib*, and
adding your syscall library and its directory at the end of the
build/ld command line.
Alternatively, you could build total replacement libraries with
your standard and syscall routines, and only include those other
parts of glib* required by gcc, some with names starting with an
_.


The interesting part of the job starts with writing tests to
verify all this stuff works: info at http://gcc.gnu.org/install
and http://gcc.gnu.org/testing


You also need to give consideration to what you will do now to
make it possible/easier to handle compiler and library upgrades
(3rd party and gcc) in the future.


Haven't done this kind of stuff with gcc, but have dealt with
similar issues.


Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Brian.Inglis@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
        fake address use address above to reply

Return to the comp.compilers page.
Search the comp.compilers archives again.