static libs... is this allowed?

Discussion in 'C++' started by Somebody, Dec 15, 2007.

  1. Somebody

    Somebody Guest

    So I'm working on a project which uses a few static libs:

    lib1.lib (support lib)
    lib2.lib (support lib)
    lib3.lib (support lib)

    mylib.lib links to lib1, lib2 and lib3

    but I noticed that lib1 has an a.obj file in it, and so does mylib.lib. The
    linker seems to toss out the lib1 (or at least the a.obj portion of it)
    completely because now the app that uses mylib.lib no longer links in static
    version. It says that functions used by mylib.lib -> a.obj (which use
    functions from lib1 -> a.obj) don't exist.

    any ideas?
    Somebody, Dec 15, 2007
    #1
    1. Advertising

  2. Somebody

    Ian Collins Guest

    Somebody wrote:
    > So I'm working on a project which uses a few static libs:
    >
    > lib1.lib (support lib)
    > lib2.lib (support lib)
    > lib3.lib (support lib)
    >
    > mylib.lib links to lib1, lib2 and lib3
    >
    > but I noticed that lib1 has an a.obj file in it, and so does mylib.lib. The
    > linker seems to toss out the lib1 (or at least the a.obj portion of it)
    > completely because now the app that uses mylib.lib no longer links in static
    > version. It says that functions used by mylib.lib -> a.obj (which use
    > functions from lib1 -> a.obj) don't exist.
    >
    > any ideas?
    >

    Try a group for your platform or tools, this isn't really a C++ question.

    --
    Ian Collins.
    Ian Collins, Dec 15, 2007
    #2
    1. Advertising

  3. Somebody

    Ron AF Greve Guest

    Hi,

    "Somebody" <> wrote in message
    news:mZY8j.17274$...
    > So I'm working on a project which uses a few static libs:
    >
    > lib1.lib (support lib)
    > lib2.lib (support lib)
    > lib3.lib (support lib)
    >
    > mylib.lib links to lib1, lib2 and lib3
    >
    > but I noticed that lib1 has an a.obj file in it, and so does mylib.lib.
    > The linker seems to toss out the lib1 (or at least the a.obj portion of
    > it) completely because now the app that uses mylib.lib no longer links in
    > static version. It says that functions used by mylib.lib -> a.obj (which
    > use functions from lib1 -> a.obj) don't exist.
    >
    > any ideas?
    >
    >

    I think you have to be more specific about what tool you use. Do you use VS?
    It is very important that every library has the same type of compile (for
    instance MT (multithreaded) ).

    Libraries do not actually link to eachother (they can depend on eachother
    though). When the final app is created everything needed is pulled from the
    (static) libraries and put in the final exe. Any dynamic libraries are also
    created and go in there own file There is nothing special having multiple
    static libraries.

    Regards, Ron AF Greve

    http://www.InformationSuperHighway.eu
    Ron AF Greve, Dec 15, 2007
    #3
  4. Somebody

    Somebody Guest

    > I think you have to be more specific about what tool you use. Do you use
    > VS? It is very important that every library has the same type of compile
    > (for instance MT (multithreaded) ).
    >
    > Libraries do not actually link to eachother (they can depend on eachother
    > though). When the final app is created everything needed is pulled from
    > the (static) libraries and put in the final exe. Any dynamic libraries are
    > also created and go in there own file There is nothing special having
    > multiple static libraries.
    >


    Yeah, I'm using Visual Studio.

    My product is a library that provides both DLL and static LIB versions. Both
    versions use Detours static lib, LibPNG static lib and ZLib static lib.

    LibPNG has a png.c file and thus produces a png.obj file.

    My DLL (or LIB) had a png.cpp file and thus produced a png.obj as well.

    When I went to build MyApp (that only links to MyDLL (or LIB)), it couldn't
    find any of the stuff thats in LibPNGs png.c.

    Actually, as I was building MyDLL in static lib format, I would get a
    warning from the linker saying "Replacing .\DebugS\png.obj". It linked
    everything else from my LibPNG project. It just dumped that one OBJ file.

    I got around this by renaming *MY* png.cpp to pngutil.cpp.
    Somebody, Dec 16, 2007
    #4
  5. Somebody

    Ron AF Greve Guest

    Hi,

    Ok, I can imagine there is a problem in that the png static library gets
    embedded in your app.exe and in the dynamic library (to be honest I am not
    sure about this).

    Since you can compile libpng also as DLL you might try that configuration
    (you probably need to do the same for zlib then). I wouldn't expect a
    conflict with (but its only a guess).


    Regards, Ron AF Greve

    http://www.InformationSuperHighway.eu

    "Somebody" <> wrote in message
    news:3XZ8j.17280$...
    >> I think you have to be more specific about what tool you use. Do you use
    >> VS? It is very important that every library has the same type of compile
    >> (for instance MT (multithreaded) ).
    >>
    >> Libraries do not actually link to eachother (they can depend on eachother
    >> though). When the final app is created everything needed is pulled from
    >> the (static) libraries and put in the final exe. Any dynamic libraries
    >> are also created and go in there own file There is nothing special having
    >> multiple static libraries.
    >>

    >
    > Yeah, I'm using Visual Studio.
    >
    > My product is a library that provides both DLL and static LIB versions.
    > Both versions use Detours static lib, LibPNG static lib and ZLib static
    > lib.
    >
    > LibPNG has a png.c file and thus produces a png.obj file.
    >
    > My DLL (or LIB) had a png.cpp file and thus produced a png.obj as well.
    >
    > When I went to build MyApp (that only links to MyDLL (or LIB)), it
    > couldn't find any of the stuff thats in LibPNGs png.c.
    >
    > Actually, as I was building MyDLL in static lib format, I would get a
    > warning from the linker saying "Replacing .\DebugS\png.obj". It linked
    > everything else from my LibPNG project. It just dumped that one OBJ file.
    >
    > I got around this by renaming *MY* png.cpp to pngutil.cpp.
    >
    >
    Ron AF Greve, Dec 16, 2007
    #5
  6. Somebody

    Boris Guest

    On Sun, 16 Dec 2007 02:03:00 +0200, Somebody <> wrote:

    > [...]Yeah, I'm using Visual Studio.
    >
    > My product is a library that provides both DLL and static LIB versions.
    > Both
    > versions use Detours static lib, LibPNG static lib and ZLib static lib.
    >
    > LibPNG has a png.c file and thus produces a png.obj file.
    >
    > My DLL (or LIB) had a png.cpp file and thus produced a png.obj as well.
    >
    > When I went to build MyApp (that only links to MyDLL (or LIB)), it
    > couldn't
    > find any of the stuff thats in LibPNGs png.c.
    >
    > Actually, as I was building MyDLL in static lib format, I would get a
    > warning from the linker saying "Replacing .\DebugS\png.obj". It linked
    > everything else from my LibPNG project. It just dumped that one OBJ file.
    >
    > I got around this by renaming *MY* png.cpp to pngutil.cpp.


    You can set the object file name for any .cpp file in Visual Studio.
    Visual Studio does this automatically if you add two .cpp files with the
    same name to a project. For the second .cpp file the .obj file created has
    the number 1 appended (eg. png1.obj instead of png.obj). That way you
    don't need to change the name of any .cpp file.

    HTH,
    Boris
    Boris, Dec 18, 2007
    #6
    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. Christoph
    Replies:
    2
    Views:
    526
    Richard Bos
    Sep 17, 2003
  2. Raman
    Replies:
    5
    Views:
    1,030
    Raman
    May 9, 2008
  3. Michael

    static libs instead of shared

    Michael, Jun 4, 2011, in forum: C++
    Replies:
    0
    Views:
    199
    Michael
    Jun 4, 2011
  4. Greg Hauptmann
    Replies:
    4
    Views:
    195
    Stefano Crocco
    Feb 7, 2009
  5. Iñaki Baz Castillo
    Replies:
    13
    Views:
    492
    Iñaki Baz Castillo
    May 1, 2011
Loading...

Share This Page