Why a static executable still needs libraries?

Discussion in 'Unix, Mac, & BSD (3D)' started by BlackSilver, Jan 12, 2014.

  1. BlackSilver

    Newcomer

    Joined:
    Dec 24, 2009
    Messages:
    17
    Likes Received:
    5
    Location:
    São Paulo
    I read in the steam console topic a comment about old games not running into new Linux distros and decided to test the UT2004 Demo. It didn't work because it needed an obsolete libstdc++.so.5. Ok then........ but why? It isn't a dynamic executable, as ldd told me, so what is going on?
     
  2. ERP

    ERP Moderator
    Moderator Veteran

    Joined:
    Feb 11, 2002
    Messages:
    3,669
    Likes Received:
    49
    Location:
    Redmond, WA
    One of the issues with Linux in particular and open source in general, is what seems to be almost complete disregard for backwards compatibility. At one point the libc libraries broke a lot of code because they optimized memcpy, and although the new implementation was in spec, code was dependent on unspecified behavior.

    At least linux allows you to have multiple versions of the same library so you can just find and install the right version.
     
  3. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    6
    I have no clue what constitutes a "dynamic executeable", but in the end there has to be a bridge between the App and the OS (unless you compile the OS in the executable...).
    The interface is generally a library, and the C-Library is alot more stable than lower layers.

    for your problem (assuming its the only thing that prevents the game from starting), youd merely need to find the correct glue in form of the correct libc. In Debian/Ubuntu you would run "apt-get install libstdc++5".
     
  4. BlackSilver

    Newcomer

    Joined:
    Dec 24, 2009
    Messages:
    17
    Likes Received:
    5
    Location:
    São Paulo
    A fully static binnary, using the -static flag to link all libraries dependencies in the executable. One that ldd says "not a dynamic executable"

    I know, my question is why it doesn't work, not the solution to it.

    As curiosity, do you remember which unspecified behavior was?
     
  5. BRiT

    BRiT (╯°□°)╯
    Moderator Legend Alpha

    Joined:
    Feb 7, 2002
    Messages:
    12,805
    Likes Received:
    9,160
    Location:
    Cleveland
    Most likely its the case where source and destination overlaps. I remember some pains with that when porting code across dozens of systems and tool chains.
     
  6. ERP

    ERP Moderator
    Moderator Veteran

    Joined:
    Feb 11, 2002
    Messages:
    3,669
    Likes Received:
    49
    Location:
    Redmond, WA
    Yup overlapping copies.
    memmove has to deal with the case, but the spec states memcpy's behavior is undefined.
    In older libc libraries they shared implementation and memcpy worked as a result with overlapped copies. Someone thought it was a good idea to optimize memcpy, which resulted in MANY apps breaking, and huge "religious" debate on whether the optimization should be removed to retain compatibility.

    It's a good example of a change MS would never make. The optimization probably has minimal impact on overall app performance in almost all cases, and the cost is many apps failing when run against later versions of the library. The argument of it being a bug in the apps is fair, but so what.
     
  7. Npl

    Npl
    Veteran

    Joined:
    Dec 19, 2004
    Messages:
    1,905
    Likes Received:
    6
    There are no fully static executables, not in windows or linux anyway. Id say this answer is just ldds way of telling you that it cant deal with this file.
    There are no static executables, unless you deal with something like MSDOS. The static switch only affects libraries where you have the choice. Having an OS with abstraction layers means you will always have decencies to this abstraction layer.
    Saving a few instructions for an overlap check, while having dozens of checks for other stuff.
    Saved practically nothing on the overhead, while breaking stuff like the flash plugin.

    ERP: cant say MS approach with say the dot net runtime is better in the long run. instead of one backwards compatible library you have 3 or 4 separate libs already, each rather big.
    Or the time where Direct3D still went through yearly changes, and older games regularly got introduced to visual defects (partially because of drivers, partially because MS wrapper for older versions).
    Or the fixed bugs in IE that break websites depending on them as feature.
     
  8. BlackSilver

    Newcomer

    Joined:
    Dec 24, 2009
    Messages:
    17
    Likes Received:
    5
    Location:
    São Paulo
    Just did the test that I found here http://msdn.microsoft.com/en-us/library/aa246468(v=vs.60).aspx and memcpy result is really screwed.
    Anyway a couple more of doubts: memcpy shouldn't be on glibc? Why it is in libstdc++ then? It isn't possible to insert memcpy on the executable? Is there a special class of functions more likely to generate this type of problem? If I have to do a binnary and intent to execute it ten years from now, it is more wise to pack all needed libraries with it than static compile it?
     
  9. ERP

    ERP Moderator
    Moderator Veteran

    Joined:
    Feb 11, 2002
    Messages:
    3,669
    Likes Received:
    49
    Location:
    Redmond, WA
    The problem with libraries/Apis in general is that applications become dependent on the behavior of the implementation documented or not as much as they do the exposed API's

    I've unfortunately spent a lot of my time recently dealing with the fast changing of API's and semantics of entry points in various open source products (and the associated dependency mess), and it still surprises me the lack of understanding of the impact of changes to core libraries, whether or not the docs stated that the behavior was undefined. Much of it is due to the developers being the most important consumers in that space, I think it's a real weakness of open source. As much as people bag on MS they are beholden to the application devs, which sometimes limits their ability to make the right decision.
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...