On 7/22/2012 00:43, Peter Rosin wrote: > On 2012-07-21 14:49, Vincent Torri wrote: >> On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin <p...@lysator.liu.se> wrote: >>> On 2012-07-21 13:16, Vincent Torri wrote: >>>> another solution is to just kill the stupid .la file. There is >>> >>> I don't think the .la file is stupid as it lists other important >>> dependencies. >> >> so what ? There is a HUGE problem, here. Currently, if a lib uses >> symbols in libuuid, it just can't be used to create progs/shared lib >> because the .la file lists it while it should (must) not. Static libs >> must not appear in the dependency_libs field. > > Oh, but static libs do need to be listed in dependency_libs as long > as there is no other place to put them. That, or static linking is not > working well at all. I'm not willing to sacrifice static linking. > >>>> absolutely NO reason to add to the linker static libraries that are >>>> ONLY used in my Evil library and that are not used elsewhere. >>>> >>>> I think that it is the best solution >>> >>> That disables (easy) static linking. I, as a library author, do not >>> like to make that policy decision for the application author. >> >> on Windows DLL are good. I already pass --disable-static to all my >> Windows builds. > > That has been argued elsewhere, but I can still see the value of the > other side. So again, I, as a library author, do not like to shove that > policy decision down the throat of my library consumers.
So how are you supposed to build it if *I* want it as a DLL? Rhetoric notwithstanding, how are you supposed to build a DLL that uses libuuid.a? No, cloning UUID constants is not a proper fix.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
