Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Qt Creator and other tools
  4. qmake: Create dll from lib?
Forum Updated to NodeBB v4.3 + New Features

qmake: Create dll from lib?

Scheduled Pinned Locked Moved Unsolved Qt Creator and other tools
15 Posts 4 Posters 5.2k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    Asperamanca
    wrote on last edited by
    #1

    I would like to generate a dll from a single lib file (Win/VC2010)
    I have set

    TEMPLATE=dll
    

    and have set correct values on the following variables: LIBS (paths and libraries), DESTDIR, MAKEFILE (only filename), QMAKE_LFLAGS (to set the PDB path)

    qmake generates a mak-File, but rejects generating the .mak.Debug and .mak.Release files with the error

    WARNING: Unable to generate output for: <correct path>/<correct filename>.mak.Debug [TEMPLATE dll]
    WARNING: Unable to generate output for: <correct path>/<correct filename>.mak.Release [TEMPLATE dll]
    

    I have activated -d option to get debug output, but (at least around the warning lines) I don't see anything that would explain it.

    Any ideas where I could look?

    raven-worxR 1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #2

      Hi,

      The template is lib whether it's a static or dynamic lib doesn't matter.

      If you don't get any .dll, did you properly do the classes exportation ?

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      1
      • A Offline
        A Offline
        Asperamanca
        wrote on last edited by
        #3

        Right, I don't do classes exportation. And it won't make sense for what I try to achieve:
        My intention isn't really building a dll, but to build a single library in a way so missing external dependencies become visible. This would allow me to trace dependencies between libs.
        My hope was to have a simple way where all symbols within a lib are exported in a dll, which would force the linker to display unresolved externals.

        1 Reply Last reply
        0
        • A Asperamanca

          I would like to generate a dll from a single lib file (Win/VC2010)
          I have set

          TEMPLATE=dll
          

          and have set correct values on the following variables: LIBS (paths and libraries), DESTDIR, MAKEFILE (only filename), QMAKE_LFLAGS (to set the PDB path)

          qmake generates a mak-File, but rejects generating the .mak.Debug and .mak.Release files with the error

          WARNING: Unable to generate output for: <correct path>/<correct filename>.mak.Debug [TEMPLATE dll]
          WARNING: Unable to generate output for: <correct path>/<correct filename>.mak.Release [TEMPLATE dll]
          

          I have activated -d option to get debug output, but (at least around the warning lines) I don't see anything that would explain it.

          Any ideas where I could look?

          raven-worxR Offline
          raven-worxR Offline
          raven-worx
          Moderators
          wrote on last edited by raven-worx
          #4

          @Asperamanca
          should be:

          TEMPLATE = lib
          

          From where do you have the dll value?!

          Edit: oops, way too late. Don't know what went wrong here.

          --- SUPPORT REQUESTS VIA CHAT WILL BE IGNORED ---
          If you have a question please use the forum so others can benefit from the solution in the future

          1 Reply Last reply
          0
          • SGaistS Offline
            SGaistS Offline
            SGaist
            Lifetime Qt Champion
            wrote on last edited by
            #5

            On Windows, if you don't export anything then there's no .dll created since there's nothing to "share". Why won't it make sense since it's what you need to achieve what you want ?

            Qt provides the necessary macros that you can easily incorporate into your code.

            It's all described here

            Interested in AI ? www.idiap.ch
            Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

            1 Reply Last reply
            1
            • A Offline
              A Offline
              Asperamanca
              wrote on last edited by Asperamanca
              #6

              I don't see how to use the macros to simply export all symbols?

              Edit: Ok, maybe I should elaborate: My goal is to make dependencies of a library visible. Linking it to a lib doesn't do that. Linking it to a dll would. However, if that would require all code files to be extended with macros exporting symbols (certainly >10000 symbols in total), it wouldn't really be worth it.

              kshegunovK 1 Reply Last reply
              0
              • A Asperamanca

                I don't see how to use the macros to simply export all symbols?

                Edit: Ok, maybe I should elaborate: My goal is to make dependencies of a library visible. Linking it to a lib doesn't do that. Linking it to a dll would. However, if that would require all code files to be extended with macros exporting symbols (certainly >10000 symbols in total), it wouldn't really be worth it.

                kshegunovK Offline
                kshegunovK Offline
                kshegunov
                Moderators
                wrote on last edited by
                #7

                @Asperamanca

                Linking it to a lib doesn't do that. Linking it to a dll would.

                This doesn't make any sense. You always (at least when working with MS's tools) link with the help of a .lib file even when linking against a .dll. There are 2 types of .lib files - a static library and an import library (for a .dll). So what are you having?

                However, if that would require all code files to be extended with macros exporting symbols (certainly >10000 symbols in total), it wouldn't really be worth it.

                It probably would, as @SGaist is correct - not exporting anything from a library will cause MS's linker to not produce a binary at all. But taking in mind this:

                My hope was to have a simple way where all symbols within a lib are exported in a dll, which would force the linker to display unresolved externals.

                Then you can just export a single dummy, thus tricking the linker to generate the binary, and ultimately it will fail on the unresolved externals.

                Read and abide by the Qt Code of Conduct

                A 1 Reply Last reply
                0
                • kshegunovK kshegunov

                  @Asperamanca

                  Linking it to a lib doesn't do that. Linking it to a dll would.

                  This doesn't make any sense. You always (at least when working with MS's tools) link with the help of a .lib file even when linking against a .dll. There are 2 types of .lib files - a static library and an import library (for a .dll). So what are you having?

                  However, if that would require all code files to be extended with macros exporting symbols (certainly >10000 symbols in total), it wouldn't really be worth it.

                  It probably would, as @SGaist is correct - not exporting anything from a library will cause MS's linker to not produce a binary at all. But taking in mind this:

                  My hope was to have a simple way where all symbols within a lib are exported in a dll, which would force the linker to display unresolved externals.

                  Then you can just export a single dummy, thus tricking the linker to generate the binary, and ultimately it will fail on the unresolved externals.

                  A Offline
                  A Offline
                  Asperamanca
                  wrote on last edited by
                  #8

                  @kshegunov said:

                  @Asperamanca

                  Linking it to a lib doesn't do that. Linking it to a dll would.

                  This doesn't make any sense. You always (at least when working with MS's tools) link with the help of a .lib file even when linking against a .dll. There are 2 types of .lib files - a static library and an import library (for a .dll). So what are you having?

                  My thought was to create a dll to make unresolved externals of a library visible (=symbols used by code that is part of the library). Maybe building a DLL is not the way to do it. I certainly have no use for the DLL itself - I currently generate the final executable by directly linking all required libs together.

                  However, if that would require all code files to be extended with macros exporting symbols (certainly >10000 symbols in total), it wouldn't really be worth it.

                  It probably would, as @SGaist is correct - not exporting anything from a library will cause MS's linker to not produce a binary at all. But taking in mind this:

                  My hope was to have a simple way where all symbols within a lib are exported in a dll, which would force the linker to display unresolved externals.

                  Then you can just export a single dummy, thus tricking the linker to generate the binary, and ultimately it will fail on the unresolved externals.

                  That sounds interesting, but I don't quite understand what you mean. Because the MS linker seems to ignore all symbols that are not used - and will not display unresolved externals for them. Exporting a single dummy would thus only display dependencies relied upon by that dummy (and the tree of dependencies behind it).

                  kshegunovK 1 Reply Last reply
                  0
                  • A Asperamanca

                    @kshegunov said:

                    @Asperamanca

                    Linking it to a lib doesn't do that. Linking it to a dll would.

                    This doesn't make any sense. You always (at least when working with MS's tools) link with the help of a .lib file even when linking against a .dll. There are 2 types of .lib files - a static library and an import library (for a .dll). So what are you having?

                    My thought was to create a dll to make unresolved externals of a library visible (=symbols used by code that is part of the library). Maybe building a DLL is not the way to do it. I certainly have no use for the DLL itself - I currently generate the final executable by directly linking all required libs together.

                    However, if that would require all code files to be extended with macros exporting symbols (certainly >10000 symbols in total), it wouldn't really be worth it.

                    It probably would, as @SGaist is correct - not exporting anything from a library will cause MS's linker to not produce a binary at all. But taking in mind this:

                    My hope was to have a simple way where all symbols within a lib are exported in a dll, which would force the linker to display unresolved externals.

                    Then you can just export a single dummy, thus tricking the linker to generate the binary, and ultimately it will fail on the unresolved externals.

                    That sounds interesting, but I don't quite understand what you mean. Because the MS linker seems to ignore all symbols that are not used - and will not display unresolved externals for them. Exporting a single dummy would thus only display dependencies relied upon by that dummy (and the tree of dependencies behind it).

                    kshegunovK Offline
                    kshegunovK Offline
                    kshegunov
                    Moderators
                    wrote on last edited by
                    #9

                    @Asperamanca

                    I currently generate the final executable by directly linking all required libs together.

                    Again, are those static libraries? This'd ensure that internally all symbols are resolved. As for the API, you need to link the .dll to the executable so the linker knows what's needed and thus generate errors.

                    Because the MS linker seems to ignore all symbols that are not used - and will not display unresolved externals for them.

                    As any linker does. It won't care about a symbol if it isn't referenced anywhere; it may even strip it from the final binary depending on the optimizations.

                    Exporting a single dummy would thus only display dependencies relied upon by that dummy (and the tree of dependencies behind it).

                    Yes, most probably I've misunderstood what you want to accomplish.

                    Read and abide by the Qt Code of Conduct

                    1 Reply Last reply
                    0
                    • A Offline
                      A Offline
                      Asperamanca
                      wrote on last edited by
                      #10

                      I'll try to better explain what I would like to achieve. I'm pretty agnostic about how to achieve it:

                      I have ~100 static lib projects (in form of .pro files). Plus a dozen or so application projects that include very little code themselves (basically only the main.cpp). The applications link the static libs together to produce the final executables.

                      So far, so good. It works.

                      However, the static libs have a complex web of dependencies to each other. Library A needs symbols from libraries B, C and D (or alternatively a dummy defined in library Z), Library B needs C, G and X, and in some cases the dependencies form recursions.

                      These dependencies only become visible when you have a specific linker problem while building an executable. That means, I can fix specific dependency problems as they appear, but I don't really "see" the web of dependencies between the libraries. And I would like to make this web visible - somehow. A start would be a list of symbols a single, isolated library needs. By parsing those lists, I could learn a lot about the inter-dependencies between the libraries, and could start thinking about improving things.

                      kshegunovK 1 Reply Last reply
                      0
                      • A Asperamanca

                        I'll try to better explain what I would like to achieve. I'm pretty agnostic about how to achieve it:

                        I have ~100 static lib projects (in form of .pro files). Plus a dozen or so application projects that include very little code themselves (basically only the main.cpp). The applications link the static libs together to produce the final executables.

                        So far, so good. It works.

                        However, the static libs have a complex web of dependencies to each other. Library A needs symbols from libraries B, C and D (or alternatively a dummy defined in library Z), Library B needs C, G and X, and in some cases the dependencies form recursions.

                        These dependencies only become visible when you have a specific linker problem while building an executable. That means, I can fix specific dependency problems as they appear, but I don't really "see" the web of dependencies between the libraries. And I would like to make this web visible - somehow. A start would be a list of symbols a single, isolated library needs. By parsing those lists, I could learn a lot about the inter-dependencies between the libraries, and could start thinking about improving things.

                        kshegunovK Offline
                        kshegunovK Offline
                        kshegunov
                        Moderators
                        wrote on last edited by
                        #11

                        @Asperamanca

                        I have ~100 static lib projects

                        Is maintaining that even realistic ...?

                        However, the static libs have a complex web of dependencies to each other. Library A needs symbols from libraries B, C and D (or alternatively a dummy defined in library Z), Library B needs C, G and X, and in some cases the dependencies form recursions.

                        Honestly, this sounds like a futile task ... I'd just group up the code into a number of dynamic libraries and resolve the dependency hell by hand and once and for all. I assume that's not what you expect or want, but I really don't think there's a better way in the long run.

                        These dependencies only become visible when you have a specific linker problem while building an executable. That means, I can fix specific dependency problems as they appear, but I don't really "see" the web of dependencies between the libraries. And I would like to make this web visible - somehow. A start would be a list of symbols a single, isolated library needs. By parsing those lists, I could learn a lot about the inter-dependencies between the libraries, and could start thinking about improving things.

                        Well, you can run an external tool to get the symbol table (undecorated) and ultimately build a fake "linker" yourself. Although, as I said, I'm suspicious of the wisdom of it ...

                        Kind regards.

                        Read and abide by the Qt Code of Conduct

                        A 1 Reply Last reply
                        0
                        • kshegunovK kshegunov

                          @Asperamanca

                          I have ~100 static lib projects

                          Is maintaining that even realistic ...?

                          However, the static libs have a complex web of dependencies to each other. Library A needs symbols from libraries B, C and D (or alternatively a dummy defined in library Z), Library B needs C, G and X, and in some cases the dependencies form recursions.

                          Honestly, this sounds like a futile task ... I'd just group up the code into a number of dynamic libraries and resolve the dependency hell by hand and once and for all. I assume that's not what you expect or want, but I really don't think there's a better way in the long run.

                          These dependencies only become visible when you have a specific linker problem while building an executable. That means, I can fix specific dependency problems as they appear, but I don't really "see" the web of dependencies between the libraries. And I would like to make this web visible - somehow. A start would be a list of symbols a single, isolated library needs. By parsing those lists, I could learn a lot about the inter-dependencies between the libraries, and could start thinking about improving things.

                          Well, you can run an external tool to get the symbol table (undecorated) and ultimately build a fake "linker" yourself. Although, as I said, I'm suspicious of the wisdom of it ...

                          Kind regards.

                          A Offline
                          A Offline
                          Asperamanca
                          wrote on last edited by
                          #12

                          @kshegunov said:

                          @Asperamanca

                          I have ~100 static lib projects

                          Is maintaining that even realistic ...?

                          Why not? As long as you have a good overview. With less lib projects, there would be more complexity hidden inside the single projects.

                          However, the static libs have a complex web of dependencies to each other. Library A needs symbols from libraries B, C and D (or alternatively a dummy defined in library Z), Library B needs C, G and X, and in some cases the dependencies form recursions.

                          Honestly, this sounds like a futile task ... I'd just group up the code into a number of dynamic libraries and resolve the dependency hell by hand and once and for all. I assume that's not what you expect or want, but I really don't think there's a better way in the long run.

                          The "once and for all" made me chuckle. Things change, the code is in flux. So are the dependencies. I don't bemoan that fact - it's part of life. Just like I wouldn't bemoan getting lost in a foreign city - I would get a map.

                          There is a good reason not to use dynamic libraries: We need to run different versions of applications side by side, without any hassle. That's very easy to do with a single resulting executable, but hard if you have dynamic libraries.

                          These dependencies only become visible when you have a specific linker problem while building an executable. That means, I can fix specific dependency problems as they appear, but I don't really "see" the web of dependencies between the libraries. And I would like to make this web visible - somehow. A start would be a list of symbols a single, isolated library needs. By parsing those lists, I could learn a lot about the inter-dependencies between the libraries, and could start thinking about improving things.

                          Well, you can run an external tool to get the symbol table (undecorated) and ultimately build a fake "linker" yourself. Although, as I said, I'm suspicious of the wisdom of it ...

                          Kind regards.

                          Which "external tool" would that be? Very interested....

                          kshegunovK 1 Reply Last reply
                          0
                          • A Asperamanca

                            @kshegunov said:

                            @Asperamanca

                            I have ~100 static lib projects

                            Is maintaining that even realistic ...?

                            Why not? As long as you have a good overview. With less lib projects, there would be more complexity hidden inside the single projects.

                            However, the static libs have a complex web of dependencies to each other. Library A needs symbols from libraries B, C and D (or alternatively a dummy defined in library Z), Library B needs C, G and X, and in some cases the dependencies form recursions.

                            Honestly, this sounds like a futile task ... I'd just group up the code into a number of dynamic libraries and resolve the dependency hell by hand and once and for all. I assume that's not what you expect or want, but I really don't think there's a better way in the long run.

                            The "once and for all" made me chuckle. Things change, the code is in flux. So are the dependencies. I don't bemoan that fact - it's part of life. Just like I wouldn't bemoan getting lost in a foreign city - I would get a map.

                            There is a good reason not to use dynamic libraries: We need to run different versions of applications side by side, without any hassle. That's very easy to do with a single resulting executable, but hard if you have dynamic libraries.

                            These dependencies only become visible when you have a specific linker problem while building an executable. That means, I can fix specific dependency problems as they appear, but I don't really "see" the web of dependencies between the libraries. And I would like to make this web visible - somehow. A start would be a list of symbols a single, isolated library needs. By parsing those lists, I could learn a lot about the inter-dependencies between the libraries, and could start thinking about improving things.

                            Well, you can run an external tool to get the symbol table (undecorated) and ultimately build a fake "linker" yourself. Although, as I said, I'm suspicious of the wisdom of it ...

                            Kind regards.

                            Which "external tool" would that be? Very interested....

                            kshegunovK Offline
                            kshegunovK Offline
                            kshegunov
                            Moderators
                            wrote on last edited by
                            #13

                            @Asperamanca

                            The "once and for all" made me chuckle.

                            I'm glad I'm providing quality entertainment.

                            Things change, the code is in flux. So are the dependencies.
                            There is a good reason not to use dynamic libraries: We need to run different versions of applications side by side, without any hassle. That's very easy to do with a single resulting executable, but hard if you have dynamic libraries.

                            Meaning one should provide API and binary compatibility, at least that's what I'd do, but it's your code and you can manage it as you see fit.

                            Which "external tool" would that be? Very interested....

                            Perhaps, this thread might be useful: http://stackoverflow.com/questions/488809/tools-for-inspecting-lib-files

                            If you're working/listing the symbols on Linux, you can use nm (readelf isn't useful here, as there's no ELF header for archives). I think for OS X the corresponding tool is otool but don't hold me to it. @SGaist can confirm or deny that last piece of information.

                            Kind regards.

                            Read and abide by the Qt Code of Conduct

                            A 1 Reply Last reply
                            0
                            • kshegunovK kshegunov

                              @Asperamanca

                              The "once and for all" made me chuckle.

                              I'm glad I'm providing quality entertainment.

                              Things change, the code is in flux. So are the dependencies.
                              There is a good reason not to use dynamic libraries: We need to run different versions of applications side by side, without any hassle. That's very easy to do with a single resulting executable, but hard if you have dynamic libraries.

                              Meaning one should provide API and binary compatibility, at least that's what I'd do, but it's your code and you can manage it as you see fit.

                              Which "external tool" would that be? Very interested....

                              Perhaps, this thread might be useful: http://stackoverflow.com/questions/488809/tools-for-inspecting-lib-files

                              If you're working/listing the symbols on Linux, you can use nm (readelf isn't useful here, as there's no ELF header for archives). I think for OS X the corresponding tool is otool but don't hold me to it. @SGaist can confirm or deny that last piece of information.

                              Kind regards.

                              A Offline
                              A Offline
                              Asperamanca
                              wrote on last edited by Asperamanca
                              #14

                              @kshegunov said:

                              @Asperamanca

                              The "once and for all" made me chuckle.

                              I'm glad I'm providing quality entertainment.

                              No hard feelings, I hope.

                              Things change, the code is in flux. So are the dependencies.
                              There is a good reason not to use dynamic libraries: We need to run different versions of applications side by side, without any hassle. That's very easy to do with a single resulting executable, but hard if you have dynamic libraries.

                              Meaning one should provide API and binary compatibility, at least that's what I'd do, but it's your code and you can manage it as you see fit.

                              Well, it's a team thing, too. I feel there is a mess that should be fixed, but to make it happen, I need to provide good arguments and some solid data.

                              Which "external tool" would that be? Very interested....

                              Perhaps, this thread might be useful: http://stackoverflow.com/questions/488809/tools-for-inspecting-lib-files

                              If you're working/listing the symbols on Linux, you can use nm (readelf isn't useful here, as there's no ELF header for archives). I think for OS X the corresponding tool is otool but don't hold me to it. @SGaist can confirm or deny that last piece of information.

                              Kind regards.

                              dumpbin -symbols might just provide what I need. Thank you!

                              kshegunovK 1 Reply Last reply
                              0
                              • A Asperamanca

                                @kshegunov said:

                                @Asperamanca

                                The "once and for all" made me chuckle.

                                I'm glad I'm providing quality entertainment.

                                No hard feelings, I hope.

                                Things change, the code is in flux. So are the dependencies.
                                There is a good reason not to use dynamic libraries: We need to run different versions of applications side by side, without any hassle. That's very easy to do with a single resulting executable, but hard if you have dynamic libraries.

                                Meaning one should provide API and binary compatibility, at least that's what I'd do, but it's your code and you can manage it as you see fit.

                                Well, it's a team thing, too. I feel there is a mess that should be fixed, but to make it happen, I need to provide good arguments and some solid data.

                                Which "external tool" would that be? Very interested....

                                Perhaps, this thread might be useful: http://stackoverflow.com/questions/488809/tools-for-inspecting-lib-files

                                If you're working/listing the symbols on Linux, you can use nm (readelf isn't useful here, as there's no ELF header for archives). I think for OS X the corresponding tool is otool but don't hold me to it. @SGaist can confirm or deny that last piece of information.

                                Kind regards.

                                dumpbin -symbols might just provide what I need. Thank you!

                                kshegunovK Offline
                                kshegunovK Offline
                                kshegunov
                                Moderators
                                wrote on last edited by
                                #15

                                @Asperamanca

                                No hard feelings, I hope.

                                No, none.

                                Well, it's a team thing, too. I feel there is a mess that should be fixed, but to make it happen, I need to provide good arguments and some solid data.

                                I'd think your best argument is any cyclic dependencies you may have. When building as dlls the linker is your last line of defence against having that kind of spaghetti-linkage. Also shared libraries are intended to be shared, which is what you describe, and the OS loader may apply few optimizations when needing to map the same library to memory multiple times.

                                Read and abide by the Qt Code of Conduct

                                1 Reply Last reply
                                0

                                • Login

                                • Login or register to search.
                                • First post
                                  Last post
                                0
                                • Categories
                                • Recent
                                • Tags
                                • Popular
                                • Users
                                • Groups
                                • Search
                                • Get Qt Extensions
                                • Unsolved