Linking in C++

Discussion in 'C++' started by jacob navia, Apr 25, 2011.

  1. jacob navia

    jacob navia Guest

    Suppose I have some class "derived" that inherits from "mainClass".

    If I call just one method from "derived", do my executable include:

    (1) Only that method from derived since I do not instantiate any
    mainClass objects

    (2) All methods of the derived class + constructor/destructor of mainClass

    (3) All methods of both classes and all methods of (possible) superclasses.

    Thanks

    jacob
     
    jacob navia, Apr 25, 2011
    #1
    1. Advertising

  2. On 4/25/2011 1:00 PM, jacob navia wrote:
    > Suppose I have some class "derived" that inherits from "mainClass".
    >
    > If I call just one method from "derived", do my executable include:
    >
    > (1) Only that method from derived since I do not instantiate any
    > mainClass objects
    >
    > (2) All methods of the derived class + constructor/destructor of mainClass
    >
    > (3) All methods of both classes and all methods of (possible) superclasses.


    This is not governed by the language standard. There are linkers that
    will remove unused functions from the object modules (so you're going to
    end up with "1"). Other linkers will leave in the entire object module
    (so you're getting "2" or "3" depending on how your code is organised).

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Apr 25, 2011
    #2
    1. Advertising

  3. jacob navia <> writes:

    > Suppose I have some class "derived" that inherits from "mainClass".
    >
    > If I call just one method from "derived", do my executable include:
    >
    > (1) Only that method from derived since I do not instantiate any
    > mainClass objects


    The called method will be included (unless it has been inlined by the
    compiler).

    > (2) All methods of the derived class + constructor/destructor of mainClass


    Other methods are not needed, but ctor and dtor of both "derived" and
    "mainClass" are actually used (instantiating "derived" indirectly
    instantiates "mainClass").

    > (3) All methods of both classes and all methods of (possible) superclasses.


    This may happen as well...

    Actually your problem has nothing to do with c++, but everything to do
    with both the compiler and the linker. What will end up in the
    executable depends on the amount of inlining performed by the compiler
    and the smartness of the linker (i.e., its ability to notice that some
    routines are unused).

    -- Alain.
     
    Alain Ketterlin, Apr 25, 2011
    #3
  4. jacob navia

    jacob navia Guest

    Le 25/04/11 19:16, Victor Bazarov a écrit :
    >
    > This is not governed by the language standard. There are linkers that
    > will remove unused functions from the object modules (so you're going to
    > end up with "1"). Other linkers will leave in the entire object module
    > (so you're getting "2" or "3" depending on how your code is organised).
    >


    Thanks for your answer Victor.
     
    jacob navia, Apr 25, 2011
    #4
  5. jacob navia

    jacob navia Guest

    Le 25/04/11 19:56, Alain Ketterlin a écrit :
    > jacob navia<> writes:
    >
    >> Suppose I have some class "derived" that inherits from "mainClass".
    >>
    >> If I call just one method from "derived", do my executable include:
    >>
    >> (1) Only that method from derived since I do not instantiate any
    >> mainClass objects

    >
    > The called method will be included (unless it has been inlined by the
    > compiler).
    >
    >> (2) All methods of the derived class + constructor/destructor of mainClass

    >
    > Other methods are not needed, but ctor and dtor of both "derived" and
    > "mainClass" are actually used (instantiating "derived" indirectly
    > instantiates "mainClass").
    >
    >> (3) All methods of both classes and all methods of (possible) superclasses.

    >
    > This may happen as well...
    >
    > Actually your problem has nothing to do with c++, but everything to do
    > with both the compiler and the linker. What will end up in the
    > executable depends on the amount of inlining performed by the compiler
    > and the smartness of the linker (i.e., its ability to notice that some
    > routines are unused).
    >



    Thanks for your answer Alain.
     
    jacob navia, Apr 25, 2011
    #5
  6. jacob navia

    James Kanze Guest

    On Apr 25, 6:16 pm, Victor Bazarov <> wrote:
    > On 4/25/2011 1:00 PM, jacob navia wrote:


    > > Suppose I have some class "derived" that inherits from
    > > "mainClass".


    > > If I call just one method from "derived", do my executable
    > > include:


    > > (1) Only that method from derived since I do not instantiate
    > > any mainClass objects


    > > (2) All methods of the derived class +
    > > constructor/destructor of mainClass


    > > (3) All methods of both classes and all methods of
    > > (possible) superclasses.


    > This is not governed by the language standard.


    It is at least partially, since you don't have to provide
    implementations for functions that are not "used". (The
    original question didn't provide enough information for us to
    state whether some other functions were "used" or not. In
    general, a virtual function is "used" as soon as there is an
    instance of the class, regardless of whether the function is
    ever actually called.)

    > There are linkers that will remove unused functions from the
    > object modules (so you're going to end up with "1"). Other
    > linkers will leave in the entire object module (so you're
    > getting "2" or "3" depending on how your code is organised).


    The granularity of most linkers is the object file. In general,
    if you are writing a library, you put each non-virtual function
    in a separate object file, and only those which are actually
    called are included. (But this is, of course, a quality of
    implementation issue for the library provider.)

    --
    James Kanze
     
    James Kanze, Apr 25, 2011
    #6
  7. jacob navia

    Ebenezer Guest

    On Apr 25, 4:53 pm, James Kanze <> wrote:
    > On Apr 25, 6:16 pm, Victor Bazarov <> wrote:
    >
    > > There are linkers that will remove unused functions from the
    > > object modules (so you're going to end up with "1").  Other
    > > linkers will leave in the entire object module (so you're
    > > getting "2" or "3" depending on how your code is organised).

    >
    > The granularity of most linkers is the object file.  In general,
    > if you are writing a library, you put each non-virtual function
    > in a separate object file, and only those which are actually
    > called are included.  (But this is, of course, a quality of
    > implementation issue for the library provider.)
    >


    This seems like a "premature optimization." I haven't come
    across this much, but recall your mentioning it previously.


    Brian Wood
    Ebenezer Enterprises
    http://webEbenezer.net
     
    Ebenezer, Apr 27, 2011
    #7
  8. jacob navia

    jacob navia Guest

    Le 27/04/11 21:01, Pete Becker a écrit :
    > On 2011-04-27 14:24:21 -0400, Ebenezer said:
    >
    >> On Apr 25, 4:53 pm, James Kanze <> wrote:
    >>> On Apr 25, 6:16 pm, Victor Bazarov <> wrote:
    >>>
    >>>> There are linkers that will remove unused functions from the
    >>>> object modules (so you're going to end up with "1"). Other
    >>>> linkers will leave in the entire object module (so you're
    >>>> getting "2" or "3" depending on how your code is organised).
    >>>
    >>> The granularity of most linkers is the object file. In general,
    >>> if you are writing a library, you put each non-virtual function
    >>> in a separate object file, and only those which are actually
    >>> called are included. (But this is, of course, a quality of
    >>> implementation issue for the library provider.)
    >>>

    >>
    >> This seems like a "premature optimization." I haven't come
    >> across this much, but recall your mentioning it previously.
    >>

    >
    > Not in a general-purpose library. If you get it wrong your customers
    > complain about code bloat. As an extreme example, linking the entire C
    > standard library into every application would not be a good thing.
    >


    For some people all optimizations are "premature" and they deliver
    bloated, unoptimized programs. Code bloat slows down programs because
    it forces more main memory reads, and makes code cacheing less
    efficient. It is a very important optimization.
     
    jacob navia, Apr 27, 2011
    #8
  9. jacob navia

    Bo Persson Guest

    Ebenezer wrote:
    > On Apr 25, 4:53 pm, James Kanze <> wrote:
    >> On Apr 25, 6:16 pm, Victor Bazarov <>
    >> wrote:
    >>
    >>> There are linkers that will remove unused functions from the
    >>> object modules (so you're going to end up with "1"). Other
    >>> linkers will leave in the entire object module (so you're
    >>> getting "2" or "3" depending on how your code is organised).

    >>
    >> The granularity of most linkers is the object file. In general,
    >> if you are writing a library, you put each non-virtual function
    >> in a separate object file, and only those which are actually
    >> called are included. (But this is, of course, a quality of
    >> implementation issue for the library provider.)
    >>

    >
    > This seems like a "premature optimization." I haven't come
    > across this much, but recall your mentioning it previously.
    >


    Some compilers will do it for you, and put each function in its own
    section. Perhaps that's why not everyone have noticed any "bloat".


    Bo Persson
     
    Bo Persson, Apr 27, 2011
    #9
  10. jacob navia

    Ebenezer Guest

    On Apr 27, 3:00 pm, "Bo Persson" <> wrote:
    > Ebenezer wrote:
    > > On Apr 25, 4:53 pm, James Kanze <> wrote:
    > >> On Apr 25, 6:16 pm, Victor Bazarov <>
    > >> wrote:

    >
    > >>> There are linkers that will remove unused functions from the
    > >>> object modules (so you're going to end up with "1"). Other
    > >>> linkers will leave in the entire object module (so you're
    > >>> getting "2" or "3" depending on how your code is organised).

    >
    > >> The granularity of most linkers is the object file. In general,
    > >> if you are writing a library, you put each non-virtual function
    > >> in a separate object file, and only those which are actually
    > >> called are included. (But this is, of course, a quality of
    > >> implementation issue for the library provider.)

    >
    > > This seems like a "premature optimization."  I haven't come
    > > across this much, but recall your mentioning it previously.

    >
    > Some compilers will do it for you, and put each function in its own
    > section. Perhaps that's why not everyone have noticed any "bloat".
    >



    What compilers do this?
    What I take away is to put a limit on the size of files.
    I think this is a reminder of the benefits of moderation.
     
    Ebenezer, Apr 28, 2011
    #10
  11. jacob navia

    Ebenezer Guest

    On Apr 27, 2:56 pm, jacob navia <> wrote:
    > Le 27/04/11 21:01, Pete Becker a crit :
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On 2011-04-27 14:24:21 -0400, Ebenezer said:

    >
    > >> On Apr 25, 4:53 pm, James Kanze <> wrote:
    > >>> On Apr 25, 6:16 pm, Victor Bazarov <> wrote:

    >
    > >>>> There are linkers that will remove unused functions from the
    > >>>> object modules (so you're going to end up with "1").  Other
    > >>>> linkers will leave in the entire object module (so you're
    > >>>> getting "2" or "3" depending on how your code is organised).

    >
    > >>> The granularity of most linkers is the object file.  In general,
    > >>> if you are writing a library, you put each non-virtual function
    > >>> in a separate object file, and only those which are actually
    > >>> called are included.  (But this is, of course, a quality of
    > >>> implementation issue for the library provider.)

    >
    > >> This seems like a "premature optimization." I haven't come
    > >> across this much, but recall your mentioning it previously.

    >
    > > Not in a general-purpose library. If you get it wrong your customers
    > > complain about code bloat. As an extreme example, linking the entire C
    > > standard library into every application would not be a good thing.

    >
    > For some people all optimizations are "premature" and they deliver
    > bloated, unoptimized programs. Code bloat slows down programs because
    > it forces more main memory reads, and makes code cacheing less
    > efficient. It is a very important optimization.



    I think this library -- http://quicklz.com -- is a
    quality library, but there's no breaking things up
    like that. I can't think of a library that splits
    things up into such small chunks.
     
    Ebenezer, Apr 28, 2011
    #11
  12. jacob navia

    Drew Lawson Guest

    In article <>
    Ebenezer <> writes:
    >On Apr 27, 2:56 pm, jacob navia <> wrote:
    >> Le 27/04/11 21:01, Pete Becker a crit :
    >>
    >> > On 2011-04-27 14:24:21 -0400, Ebenezer said:

    >>
    >> >> On Apr 25, 4:53 pm, James Kanze <> wrote:

    >>
    >> >>> The granularity of most linkers is the object file.  In general,
    >> >>> if you are writing a library, you put each non-virtual function
    >> >>> in a separate object file, and only those which are actually
    >> >>> called are included.  (But this is, of course, a quality of
    >> >>> implementation issue for the library provider.)

    >>
    >> >> This seems like a "premature optimization." I haven't come
    >> >> across this much, but recall your mentioning it previously.

    >>
    >> > Not in a general-purpose library. If you get it wrong your customers
    >> > complain about code bloat. As an extreme example, linking the entire C
    >> > standard library into every application would not be a good thing.

    >>
    >> For some people all optimizations are "premature" and they deliver
    >> bloated, unoptimized programs. Code bloat slows down programs because
    >> it forces more main memory reads, and makes code cacheing less
    >> efficient. It is a very important optimization.

    >
    >
    >I think this library -- http://quicklz.com -- is a
    >quality library, but there's no breaking things up
    >like that. I can't think of a library that splits
    >things up into such small chunks.


    Taking a quick look at libc on my FreeBSD system, I see that it is
    split into 849 files. I find this pretty common for general use
    libraries.
    Less general libraries -- database APIs, toolsets, etc. -- probably
    don't take that effort as often.

    --
    Drew Lawson | And to those who lack the courage
    | And say it's dangerous to try
    | Well they just don't know
    | That love eternal will not be denied
     
    Drew Lawson, Apr 28, 2011
    #12
  13. jacob navia

    gwowen Guest

    On Apr 28, 2:23 pm, (Drew Lawson) wrote:
    > In article <..com>
    >         Ebenezer <> writes:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > >On Apr 27, 2:56 pm, jacob navia <> wrote:
    > >> Le 27/04/11 21:01, Pete Becker a crit :

    >
    > >> > On 2011-04-27 14:24:21 -0400, Ebenezer said:

    >
    > >> >> On Apr 25, 4:53 pm, James Kanze <> wrote:

    >
    > >> >>> The granularity of most linkers is the object file. In general,
    > >> >>> if you are writing a library, you put each non-virtual function
    > >> >>> in a separate object file, and only those which are actually
    > >> >>> called are included. (But this is, of course, a quality of
    > >> >>> implementation issue for the library provider.)

    >
    > >> >> This seems like a "premature optimization." I haven't come
    > >> >> across this much, but recall your mentioning it previously.

    >
    > >> > Not in a general-purpose library. If you get it wrong your customers
    > >> > complain about code bloat. As an extreme example, linking the entireC
    > >> > standard library into every application would not be a good thing.

    >
    > >> For some people all optimizations are "premature" and they deliver
    > >> bloated, unoptimized programs. Code bloat slows down programs because
    > >> it forces more main memory reads, and makes code cacheing less
    > >> efficient. It is a very important optimization.

    >
    > >I think this library --http://quicklz.com--  is a
    > >quality library, but there's no breaking things up
    > >like that.  I can't think of a library that splits
    > >things up into such small chunks.

    >
    > Taking a quick look at libc on my FreeBSD system, I see that it is
    > split into 849 files.  I find this pretty common for general use
    > libraries.
    > Less general libraries -- database APIs, toolsets, etc. -- probably
    > don't take that effort as often.


    running

    nm /usr/lib/libc.a | grep -F ".o:" | wc -l

    on this Ubuntu Linux box suggests 1479 distinct ibject files in the
    static library

    nm /usr/lib/libc.a 2> /dev/null | grep " T " | wc -l

    suggests 2377 defined global symbols, or about 1.5 exported symbols
    per object file.
     
    gwowen, Apr 28, 2011
    #13
  14. jacob navia

    red floyd Guest

    On Apr 28, 7:01 am, gwowen <> wrote:
    > On Apr 28, 2:23 pm, (Drew Lawson) wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > In article <>
    > >         Ebenezer <> writes:

    >
    > > >On Apr 27, 2:56 pm, jacob navia <> wrote:
    > > >> Le 27/04/11 21:01, Pete Becker a crit :

    >
    > > >> > On 2011-04-27 14:24:21 -0400, Ebenezer said:

    >
    > > >> >> On Apr 25, 4:53 pm, James Kanze <> wrote:

    >
    > > >> >>> The granularity of most linkers is the object file. In general,
    > > >> >>> if you are writing a library, you put each non-virtual function
    > > >> >>> in a separate object file, and only those which are actually
    > > >> >>> called are included. (But this is, of course, a quality of
    > > >> >>> implementation issue for the library provider.)

    >
    > > >> >> This seems like a "premature optimization." I haven't come
    > > >> >> across this much, but recall your mentioning it previously.

    >
    > > >> > Not in a general-purpose library. If you get it wrong your customers
    > > >> > complain about code bloat. As an extreme example, linking the entire C
    > > >> > standard library into every application would not be a good thing.

    >
    > > >> For some people all optimizations are "premature" and they deliver
    > > >> bloated, unoptimized programs. Code bloat slows down programs because
    > > >> it forces more main memory reads, and makes code cacheing less
    > > >> efficient. It is a very important optimization.

    >
    > > >I think this library --http://quicklz.com-- is a
    > > >quality library, but there's no breaking things up
    > > >like that.  I can't think of a library that splits
    > > >things up into such small chunks.

    >
    > > Taking a quick look at libc on my FreeBSD system, I see that it is
    > > split into 849 files.  I find this pretty common for general use
    > > libraries.
    > > Less general libraries -- database APIs, toolsets, etc. -- probably
    > > don't take that effort as often.

    >
    > running
    >
    > nm /usr/lib/libc.a | grep -F ".o:" | wc -l
    >
    > on this Ubuntu Linux box suggests 1479 distinct ibject files in the
    > static library
    >
    > nm /usr/lib/libc.a 2> /dev/null | grep  " T " | wc -l
    >
    > suggests 2377 defined global symbols, or about 1.5 exported symbols
    > per object file.


    An easier way to do it:

    On RHEL 5,

    ar tv /usr/lib/libc.a | wc

    shows 1391 object files
     
    red floyd, Apr 28, 2011
    #14
  15. jacob navia

    Ebenezer Guest

    On Apr 28, 9:01 am, gwowen <> wrote:
    > On Apr 28, 2:23 pm, (Drew Lawson) wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > In article <>
    > >         Ebenezer <> writes:

    >
    > > >On Apr 27, 2:56 pm, jacob navia <> wrote:
    > > >> Le 27/04/11 21:01, Pete Becker a crit :

    >
    > > >> > On 2011-04-27 14:24:21 -0400, Ebenezer said:

    >
    > > >> >> On Apr 25, 4:53 pm, James Kanze <> wrote:

    >
    > > >> >>> The granularity of most linkers is the object file. In general,
    > > >> >>> if you are writing a library, you put each non-virtual function
    > > >> >>> in a separate object file, and only those which are actually
    > > >> >>> called are included. (But this is, of course, a quality of
    > > >> >>> implementation issue for the library provider.)

    >
    > > >> >> This seems like a "premature optimization." I haven't come
    > > >> >> across this much, but recall your mentioning it previously.

    >
    > > >> > Not in a general-purpose library. If you get it wrong your customers
    > > >> > complain about code bloat. As an extreme example, linking the entire C
    > > >> > standard library into every application would not be a good thing.

    >
    > > >> For some people all optimizations are "premature" and they deliver
    > > >> bloated, unoptimized programs. Code bloat slows down programs because
    > > >> it forces more main memory reads, and makes code cacheing less
    > > >> efficient. It is a very important optimization.

    >
    > > >I think this library --http://quicklz.com-- is a
    > > >quality library, but there's no breaking things up
    > > >like that.  I can't think of a library that splits
    > > >things up into such small chunks.

    >
    > > Taking a quick look at libc on my FreeBSD system, I see that it is
    > > split into 849 files.  I find this pretty common for general use
    > > libraries.
    > > Less general libraries -- database APIs, toolsets, etc. -- probably
    > > don't take that effort as often.

    >
    > running
    >
    > nm /usr/lib/libc.a | grep -F ".o:" | wc -l
    >
    > on this Ubuntu Linux box suggests 1479 distinct ibject files in the
    > static library
    >
    > nm /usr/lib/libc.a 2> /dev/null | grep  " T " | wc -l
    >
    > suggests 2377 defined global symbols, or about 1.5 exported symbols
    > per object file.


    Thanks for the commands. What about the little " t "'s in nm output?

    I checked my library like you did with libc and got a ratio of 4.
     
    Ebenezer, Apr 28, 2011
    #15
  16. jacob navia

    Ebenezer Guest

    On Apr 27, 6:49 pm, Ebenezer <> wrote:
    > On Apr 27, 3:00 pm, "Bo Persson" <> wrote:
    >
    > > Ebenezer wrote:
    > > > On Apr 25, 4:53 pm, James Kanze <> wrote:
    > > >> The granularity of most linkers is the object file. In general,
    > > >> if you are writing a library, you put each non-virtual function
    > > >> in a separate object file, and only those which are actually
    > > >> called are included. (But this is, of course, a quality of
    > > >> implementation issue for the library provider.)

    >
    > > > This seems like a "prematureoptimization."  I haven't come
    > > > across this much, but recall your mentioning it previously.

    >
    > > Some compilers will do it for you, and put each function in its own
    > > section. Perhaps that's why not everyone have noticed any "bloat".

    >
    > What compilers do this?


    I'd like to give a shout out to the vendors that have done
    things right in this regard. Who are the good guys in this
    story?

    I've made some changes to my work related to this.
    Previously I had this "middle" file:

    local_messages
    (cmw_request)

    (bool)
    (bool, flex_string<char>) @out
    (flex_string<char>) @in
    }

    ----------------------------------------------------

    A line like (cmw_request) caused both a Send and
    Receive function to be created. And the class
    that was created, local_messages, was shared by
    two executables. Now I've changed the middle file
    so two separate classes are created:

    local_messages
    (cmw_request) @in

    (bool) @out
    (bool, flex_string<char>) @out
    }

    local_messages_d
    (cmw_request) @out

    (bool) @in
    (flex_string<char>) @in
    }

    -------------------------------------------------

    Using this approach has reduced the size of the
    two executables by 300 to 400 bytes each. It also
    provides a nice application of the support for
    multiple classes being outlined in a middle file.


    Brian Wood
     
    Ebenezer, May 4, 2011
    #16
  17. jacob navia

    Marc Guest

    Ebenezer wrote:

    > On Apr 27, 3:00 pm, "Bo Persson" <> wrote:


    >> Some compilers will do it for you, and put each function in its own
    >> section. Perhaps that's why not everyone have noticed any "bloat".

    >
    > What compilers do this?


    For instance:
    gcc -ffunction-sections

    (I don't know what compilers do it by default)
     
    Marc, May 4, 2011
    #17
  18. jacob navia

    Ebenezer Guest

    On May 4, 12:04 pm, Marc <> wrote:
    > Ebenezer  wrote:
    > > On Apr 27, 3:00 pm, "Bo Persson" <> wrote:
    > >> Some compilers will do it for you, and put each function in its own
    > >> section. Perhaps that's why not everyone have noticed any "bloat".

    >
    > > What compilers do this?

    >
    > For instance:
    > gcc -ffunction-sections
    >



    I just tried that with the combined/shared class I mentioned.
    Unfortunately, the sizes of the executables are not reduced
    by that option. I used -ffunction-sections when building
    the object files and the executables. I didn't do anything
    different when building the library.
     
    Ebenezer, May 4, 2011
    #18
  19. jacob navia

    Dombo Guest

    Op 28-Apr-11 1:49, Ebenezer schreef:
    > On Apr 27, 3:00 pm, "Bo Persson"<> wrote:
    >> Ebenezer wrote:
    >>> On Apr 25, 4:53 pm, James Kanze<> wrote:
    >>>> On Apr 25, 6:16 pm, Victor Bazarov<>
    >>>> wrote:

    >>
    >>>>> There are linkers that will remove unused functions from the
    >>>>> object modules (so you're going to end up with "1"). Other
    >>>>> linkers will leave in the entire object module (so you're
    >>>>> getting "2" or "3" depending on how your code is organised).

    >>
    >>>> The granularity of most linkers is the object file. In general,
    >>>> if you are writing a library, you put each non-virtual function
    >>>> in a separate object file, and only those which are actually
    >>>> called are included. (But this is, of course, a quality of
    >>>> implementation issue for the library provider.)

    >>
    >>> This seems like a "premature optimization." I haven't come
    >>> across this much, but recall your mentioning it previously.

    >>
    >> Some compilers will do it for you, and put each function in its own
    >> section. Perhaps that's why not everyone have noticed any "bloat".

    >
    > What compilers do this?


    Even Microsoft Visual C++ 6.0, which was released well over a decade
    ago, could do this.
     
    Dombo, May 4, 2011
    #19
  20. jacob navia

    Marc Guest

    On 4 mai, 20:03, Ebenezer <> wrote:
    > On May 4, 12:04 pm, Marc <> wrote:
    > > Ebenezer  wrote:
    > > > On Apr 27, 3:00 pm, "Bo Persson" <> wrote:
    > > >> Some compilers will do it for you, and put each function in its own
    > > >> section. Perhaps that's why not everyone have noticed any "bloat".
    > > > What compilers do this?

    > > For instance:
    > > gcc -ffunction-sections

    > I just tried that with the combined/shared class I mentioned.
    > Unfortunately, the sizes of the executables are not reduced
    > by that option.


    You may also want to look at the --gc-sections option of ld.
     
    Marc, May 7, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guest

    not linking msvcr70.dll

    Guest, Aug 11, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    974
    Guest
    Aug 11, 2004
  2. tinoosh

    Linking problem in Primetime

    tinoosh, May 6, 2005, in forum: VHDL
    Replies:
    1
    Views:
    632
    topgun
    May 9, 2005
  3. Aditya

    Linking PDF forms with SQL

    Aditya, Aug 12, 2003, in forum: Perl
    Replies:
    0
    Views:
    2,051
    Aditya
    Aug 12, 2003
  4. Sanjay Tibrewal
    Replies:
    0
    Views:
    748
    Sanjay Tibrewal
    Nov 14, 2003
  5. alex
    Replies:
    0
    Views:
    333
Loading...

Share This Page