From: Pete B. <pb...@gm...> - 2010-08-05 16:50:07
|
On 2010.08.05 17:09, Michael Plante wrote: > They both go in system32 under no subdirectory. If you want to use both a release and a debug DLL from system32, at the same time, that's your problem, not libusb's. We don't see Linux/Darwin people asking us to ensure that a libusb debug library should be created with a different name so that they can copy both to /usr/lib. Why should it be any different for Windows? The way I see it is you want libusb to address a problem that it shouldn't be addressing. If you need libraries with different names, you can rename them. The default of MS development tools is to create debug and release libraries in different directories, but with the same name. If having automated suffixes was that crucial to developers, I'd expect Microsoft to have done something about it by now in their defaults. The only part where they have added suffixes is for crucial system libraries that would be very inconvenient having to replace while the system is running (MSVCRT being one of them). I don't think libusb is such a library yet. You can easily go into system32 and replace the DLL, without other applications coming crashing down so I don't really see much of an incentive to use suffixes when end users can rename DLLs as they see fit. >> 3. Suffixes make it inconvenient for the casual user to simply drop a >>> debug library in lieu of a release one, and expect things to work >>> *unless* both libraries are named the same. > > And that is intentional. Linking with the debug build needs to be > different. Note msvcrtd.dll vs msvcrt.dll, and ditto for all the mfc > libraries, for instance. There are plenty of others. You're talking about linking whereas I'm talking about dropping a fully built debug DLL in system32 (which seemed to be your original problem). If I pick up the libusb-1.0_debug.dll rename it to libusb-1.0.dll, drop it into System32 and use it against a dynamically linked Release (or debug) version of xusb.exe, it just works. So why is the suffix important again? I'm not seeing having no suffix on the debug lib as preventing linking against msvcrtd.dll when buidling the app in debug mode. Or does a MSVCRT.DLL dependent DLL check its name at runtime to find out whether it should use MSVCRT or MSVCRTd? Nope, that's done at runtime. So it all revolves around the inconvenience of having to rename a DLL manually in case you want to use the same DLL twice in the same directory. >>> 4. If we start using different names for debug and release on Windows, >>> then there's no reason we shouldn't do the same on >>> Linux/Darwin/MinGW/cygwin for -g / without -g. > > I don't know enough about how mingw/cygwin handle malloc, but malloc is, > afaik, the primary reason they're named differently. We went over this very > early on. Again, does a debug dynamic library need to check its name to figure out what malloc it should use? >>> 5. Any renaming of the debug libraries should be the responsibility of >>> the end users, really. > > What, like the calling convention should also be the users' responsibility? > Anything in the DLL needs to be gotten right the first time, precisely > because it's shared amongst users. You don't usually share debug DLLs. You share a calling convention. That's a major difference. Also, since when are our users expected to need to run both debug and release DLLs from System32 at the same time? Where's the common scenario for that? If someone needs to run a dynamically linked debug and release app at the same time, and use 2 different DLLs, system32 is the last place they should place DLLs. Uisng 2 app dirs with different DLLs in there is they way to go. Or why not create a System32_debug for debug DLLs and instruct your debug application to search for DLLs in that directory as well? Do you know of other projects that provide different suffixes for debug and release? If I look at pthread-win32 for one, what I'm seeing is the Microsoft established way of using different directories with the same DLL name: ftp://sourceware.org/pub/pthreads-win32/sources/pthreads-w32-2-8-0-release/pthread.dsp (/out:".\pthreadVC2.dll" for both Release and Debug) What's good enough for pthread-win32 should be good enough for us. Regards, /Pete |