Hi all
Does GPC link against glibc? I built GPC on a Redhat 7.1 machine and compiled a program there. The program won't run on a Redhat 6.2 machine. It dies with a message "/lib/libc.so.6: version 'GLIBC_2.2' not found ...".
I thought that GPC only links 'libgcc.a'. What gives? And how can I force GPC to link only to static libraries?
Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
Does GPC link against glibc? I built GPC on a Redhat 7.1 machine and compiled a program there. The program won't run on a Redhat 6.2 machine. It dies with a message "/lib/libc.so.6: version 'GLIBC_2.2' not found ...".
I thought that GPC only links 'libgcc.a'. What gives?
GPC, like almost all programs, links against libc (which provides the interface to the system functions, while libgcc only provides only a few special support routines needed on a platform, such as (I think) 64 bit arithmetic on 32 bit machines).
And how can I force GPC to link only to static libraries?
-static
When building GPC, pass it in CFLAGS to make, when compiling programs with GPC, just give it on the command line.
Frank
On 15 Sep 2001, at 20:57, Frank Heckenbach wrote:
Prof Abimbola Olowofoyeku wrote:
Does GPC link against glibc? I built GPC on a Redhat 7.1 machine and compiled a program there. The program won't run on a Redhat 6.2 machine. It dies with a message "/lib/libc.so.6: version 'GLIBC_2.2' not found ...".
I thought that GPC only links 'libgcc.a'. What gives?
GPC, like almost all programs, links against libc (which provides the interface to the system functions, while libgcc only provides only a few special support routines needed on a platform, such as (I think) 64 bit arithmetic on 32 bit machines).
I see that I've got it all wrong. All the time, I thought that libgcc was *the* C library.
And how can I force GPC to link only to static libraries?
-static
When building GPC, pass it in CFLAGS to make, when compiling programs with GPC, just give it on the command line.
Ok, thanks. Presumably, this means that the binaries will then become much bigger. Does this have any implications for execution speed and /or RAM usage?
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
And how can I force GPC to link only to static libraries?
-static
When building GPC, pass it in CFLAGS to make, when compiling programs with GPC, just give it on the command line.
Ok, thanks. Presumably, this means that the binaries will then become much bigger.
Sure.
Does this have any implications for execution speed
Depending on the processor, it will be a little faster (I heard some 3-5% on x86).
and /or RAM usage?
Bigger, of course (on the order of a few hundred KB). Of course, this might also slow down execuution a little because of more cache misses, but this shouldn't matter much.
In fact, I distribute all PENG binaries for Linux statically linked because of the issue you described, and I haven't had any problems with that.
Frank
and /or RAM usage?
Bigger, of course (on the order of a few hundred KB). Of course, this might also slow down execuution a little because of more cache misses, but this shouldn't matter much.
Afaik cache hits are better when compiled statically? This because unused code is stripped out?
Marco van de Voort wrote:
and /or RAM usage?
Bigger, of course (on the order of a few hundred KB). Of course, this might also slow down execuution a little because of more cache misses, but this shouldn't matter much.
Afaik cache hits are better when compiled statically? This because unused code is stripped out?
This can be so. OTOH, if much library code is shared between executables (and especially in tha case of libc, there are always a number of executables using it running) and it's cached because of them, anyway ...
So I suppose it depends on the circumstances what the net effect is, but in most cases I guess it's smaller than the (little) speed-up gained by non position independent code (on the x86; there are other processors where all code is position independent).
The main disadvantages of static linking are slightly increased RAM usage and having to recompile if a serious bug in the library is found (while dynamically linked programs will use a new library version as soon as it's installed).
Frank
On Mon, 17 Sep 2001, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
And how can I force GPC to link only to static libraries?
-static
When building GPC, pass it in CFLAGS to make, when compiling programs with GPC, just give it on the command line.
Ok, thanks. Presumably, this means that the binaries will then become much bigger.
Sure.
Bigger, of course (on the order of a few hundred KB)....
Can be much more. Take the classic "hello world" as an example:
size in bytes after using strip dynamic linking: 503014 165904 static linking 2379490 579220
Since this is more than you'd expect for such a simple program, I think the problem is the linker - although you have less overhead with static linking ( hence faster ), the linker does not know how to omit unused library code.
Russ
On 17 Sep 01, at 23:04, Russell Whitaker wrote:
[static linking]
Bigger, of course (on the order of a few hundred KB)....
Can be much more. Take the classic "hello world" as an example:
size in bytes after using stripdynamic linking: 503014 165904 static linking 2379490 579220
Since this is more than you'd expect for such a simple program, I think the problem is the linker - although you have less overhead with static linking ( hence faster ), the linker does not know how to omit unused library code.
The linker doesn't seem to be very "smart" in this respect. Is there any hope of a smart linker for GCC or GPC? The GNU guys are so clever at doing so many amazing things that it seems odd that they cannot (or probably will not) produce a smart linker.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com
static linking 2379490 579220
Since this is more than you'd expect for such a simple program, I think the problem is the linker - although you have less overhead with static linking ( hence faster ), the linker does not know how to omit unused library code.
The linker doesn't seem to be very "smart" in this respect. Is there any hope of a smart linker for GCC or GPC? The GNU guys are so clever at doing so many amazing things that it seems odd that they cannot (or probably will not) produce a smart linker.
(Maybe I sent this to the list earlier, sorry, group reply confusal)
Simply having GPC split up all sources to a symbol per assemblerfile and AR'ing the resulting pack to a .a would also do the trick.
It is how FPC smartlinks (with LD!)
On 18 Sep 2001, at 9:40, Marco van de Voort wrote:
static linking 2379490 579220
Since this is more than you'd expect for such a simple program, I think the problem is the linker - although you have less overhead with static linking ( hence faster ), the linker does not know how to omit unused library code.
The linker doesn't seem to be very "smart" in this respect. Is there any hope of a smart linker for GCC or GPC? The GNU guys are so clever at doing so many amazing things that it seems odd that they cannot (or probably will not) produce a smart linker.
(Maybe I sent this to the list earlier, sorry, group reply confusal)
Simply having GPC split up all sources to a symbol per assemblerfile and AR'ing the resulting pack to a .a would also do the trick.
It is how FPC smartlinks (with LD!)
Any chance of this being done with GPC? I guess that Peter is very busy at the moment - but can anyone else do it (or explain how it can be done)? Thanks.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
It is how FPC smartlinks (with LD!)
Any chance of this being done with GPC? I guess that Peter is very busy at the moment - but can anyone else do it (or explain how it can be done)? Thanks.
FPC does this internally, but maybe it could be done without changes in GPC?
One should create a .s parser that can detect global syms and breaks the .s in pieces there, piping the different small .s files to the back end .assembler
so e.g.
- compiler pipes gpc.s to our filter program. - the filter program splits gpc.s per global symbol up in gpc00.s gpc01.s gpc02.s etc - the filter programs pipes each .s separately through as, generating a .o per .s - all .s files are combined to a .a by AR, which is executed by the filterprogram
It is DOG slow (which is the reason that it is internal in FPC now), but could be handy for release versions.
E.g. a windows API unit generates 20000 .s files.
Marco van de Voort wrote:
One should create a .s parser that can detect global syms and breaks the .s in pieces there, piping the different small .s files to the back end .assembler
so e.g.
- compiler pipes gpc.s to our filter program.
- the filter program splits gpc.s per global symbol up in gpc00.s gpc01.s gpc02.s etc
- the filter programs pipes each .s separately through as, generating a .o per .s
- all .s files are combined to a .a by AR, which is executed by the filterprogram
Actually, I've had exactly the same idea -- but no time yet to pursue it further ...
It is DOG slow (which is the reason that it is internal in FPC now), but could be handy for release versions.
I'm not so sure. The splitting program would probably do relatively simple text manipulations which are quite fast, and the assembler usually takes only a tiny fraction of compile time, so even multiple invocations shouldn't take too long. (This might vary a little on systems like windoze which have such a large process spawning overhead -- at least as far as I've heard.)
E.g. a windows API unit generates 20000 .s files.
Nope. They're just external declarations that don't produce any code of their own. Such a unit would be only one file (in fact, such units currently have very small .o files and large .gpi files which are not relevant for linking and executable size, of course). Only routines with Pascal implementations (and global variables) would need to be split.
Frank
On 18 Sep 2001, at 20:38, Frank Heckenbach wrote:
Marco van de Voort wrote:
One should create a .s parser that can detect global syms and breaks the .s in pieces there, piping the different small .s files to the back end .assembler
so e.g.
- compiler pipes gpc.s to our filter program.
- the filter program splits gpc.s per global symbol up in gpc00.s
gpc01.s gpc02.s etc - the filter programs pipes each .s separately through as, generating a .o per .s - all .s files are combined to a .a by AR, which is executed by the filterprogram
Actually, I've had exactly the same idea -- but no time yet to pursue it further ...
This sounds promising ...
[...]
E.g. a windows API unit generates 20000 .s files.
Nope. They're just external declarations that don't produce any code of their own. Such a unit would be only one file (in fact, such units currently have very small .o files and large .gpi files which are not relevant for linking and executable size, of course).
True. My "Windows" unit which imports most of the Win32 API has a .o file that is 3k in size and a .gpi file that is 2.2mb in size ...
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
Russell Whitaker wrote:
Ok, thanks. Presumably, this means that the binaries will then become much bigger.
Sure.
Bigger, of course (on the order of a few hundred KB)....
Can be much more. Take the classic "hello world" as an example:
size in bytes after using stripdynamic linking: 503014 165904 static linking 2379490 579220
I was referring to stripped executables.
Frank
-
Frank Heckenbach -
marcov＠stack.nl -
Prof Abimbola Olowofoyeku -
Prof. A Olowofoyeku (The African Chief)
-
Russell Whitaker