Re: Re[2]: DLL naming conventions
On Fri, Sep 01, 2000 at 07:40:09PM +0300, Paul Sokolovsky wrote: > Hello Charles, > > Charles S. Wilson <[EMAIL PROTECTED]> wrote: > > CSW> Well, the problem with libtool is that it's a developer's tool. Take > CSW> the gettext package, for instance. It uses some version of libtool that > CSW> does not understand cygwin/dlls. The only way to 'fix' it is to replace > CSW> the libtool that is distributed WITH gettext, with a newer version. > > Yep, it's all about doing 'libtoolize --force'. When that will > work (I mean, it will be possible to take some existing GNU/*nix > package, run libtoolize --force/aclocal/automake -a/autoconf and have > it compile cute little dll without any other changes), wouldn't it be > nice? This will never work reliably. If a configure.in file (hell, the entire package configuration) was written for an old version of autoconf/automake/libtool, a forced configury upgrade can cause all sorts of problems... I'll concede that some of the time (if the author of the original configury wasn't too ambitious) brute force will work. There is no way to guarantee that it will work though. > CSW> See, libtool isn't a tool that lives on the end-user's system. It's a > CSW> couple of scripts that are distributed with each package that uses > CSW> libtool. So, you've probably got 27 versions of libtool on your system > CSW> right now. > > Yes - it is *developer* tool. But see what Gary Vaugham says: Gary Vaughan > "remember that libtool only want's you to see (and thus link against) > the libfoo.la file". That's nice, but on typical *nix system you can > build shared lib with libtool, but link against it without it. But > they want to deprive win32 users off such possibility! (Technical > note: what corresponds to shared library on *nix system is a pair of > on win32. *Pair*) You're right. I remember why I did it this way now -- the libtool machinery is not at all equipped to deal with a shared library that is not in a single file. It is a fair amount of work to teach it to understand that. I do agree that libtool could be nicer to the world by installing an appropriate implib. > CSW> Perhaps the current version of libtool groks cygwin dlls. (In the 'old' > CSW> dlltool way; I'm positive it doesn't use 'gcc -shared'). > > Yes. And know why? Because they want to support outdated betas! That was then. When we had that conversation you still needed to use dlltool on the latest net release of cygwin at that time. I would very much like to get rid of the dlltool dependency before 1.4 is released. > Note - *beta* versions of systems, for which official release is > available for quite some time. Suppose libtool supported some NeXT > alpha or Solaris pre-release of early '90? Nor even it is standard > practise - I with regret read about dropping support of some systems > in gdb 5.0. My last argument would be as follows: > > Suppose someone has cygwin b19 and libtool 1.2 and he wants to > build DLLs with it. But he can't - libtool 1.2 simply doesn't support > building DLLs! So, he's got to upgrade to libtool 1.3.x, but the same way, > he might upgrade cygwin to 1.1 also. So, rule is simple: want DLLs - use > release of cygwin and fresh libtool. Before that, there was some > support, but it was experimental and changes since. Don't want to > upgrade - enjoy static linking which is always available. > > CSW> But none of the commonly-used libraries or applications out there USE the most > CSW> current libtool. > > Libtool has quite stable usage interface and principles. Following > to them will allow to build shared libraries on *any* system with a > handful of sanity (win32 goes into this category). Matter is > implementing support for different systems. It is only the case that libtool adoption among non-GNU packages is low. Almost everything you can download from ftp.gnu.org that builds a library uses libtool these days. If I (or you Paul) can make libtool a better citizen in the Cygwin environment, I'd like to think that cygwin porters would port non-cygwin packages to libtool so that everyone can enjoy the benefits of shared libraries in those packages -- rather than cygwin specific ports which probably won't even be accepted into the upstream package. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
Archive library breakage on standard UNIX systems with ranlib
Hi there, The current libtool, both -rHEAD and -rmulti-language-branch, ever since 1999- 10-01 in fact, causes catastrophic breakage on standard UNIX systems on which archives created by ar MUST be ranlib'ed before ld can use them at all (at least 4.0BSD through 4.3BSD, and lots of others I'm sure). I have traced the breakage down to this change: 1999-10-01 Gary V. Vaughan <[EMAIL PROTECTED]> * configure.in (AC_OUTPUT_COMMANDS): generate ltmain.sh * Makefile.am (ltmain.sh ltconfig): removed. Automake inserts the rules to automatically call config.status. * libtool.m4: be sure to AC_SUBST values no longer tested in ltconfig.in. * ltconfig.in: replaced several of the simple feature tests with substitutions from config.status. ^ * Makefile.am (ltconfig): generate ltconfig with config.status. * configure.in (AC_OUTPUT): generate ltconfig with config.status. especially the highlighted part. Before this change, ltconfig.in contained the following code: if test -n "$ac_cv_prog_RANLIB"; then RANLIB="$ac_cv_prog_RANLIB" old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib" old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds" echo "$ac_t$RANLIB" 1>&6 else echo "$ac_t""no" 1>&6 fi Gary's change removed this code and switched to configure's standard ranlib check. But this is more than just a standard configure check! See how it adds ranlib commands to old_archive_cmds and old_postinstall_cmds. After Gary's change old_archive_cmds and old_postinstall_cmds never contain ranlib commands. As a result, the archive is built with ar but not ranlib'ed, causing catastrophic breakage on all standard UNIX systems on which archives created by ar must be ranlib'ed before ld can use them. The breakage caused by this change currently exists on both -rHEAD and -rmulti- language-branch and needs to be fixed in both places. However, I'm not sure what's the right way to fix this in the current libtool given all the changes since then. Can someone please fix this? TIA. -- Michael Sokolov Harhan Engineering Laboratory Public Service AgentInternational Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: [EMAIL PROTECTED] (ARPA TCP/SMTP) (UUCP coming soon) P.S. I don't subscribe to the libtool lists (only to the Cygnus tree ones), so please Cc: me.
Re: DLL naming conventions
"Gary V. Vaughan" wrote: > > Charles S. Wilson wrote: > > > > There is *something* in the windows system that gets notified that > > myapp.exe depends on mydll.dll whenever you execute myapp.exe. This > > *something* searches the file system according to the search path > > described earlier in this thread, loads the dll into the executable > > process's memeory space (rebasing the memory location if necessary), and > > fixes up all the internal pointers to match the in-process virtual > > memory location. > > > > Isn't that considered a dynamic linker? (Whether you call that > > *something* a dynamic linker or not is really immaterial. The > > *something* is a runtime loader, and that's what the reference above is > > discussing) > > Nope. Tor is correct. The libtool versioning system assumes that the > runtime loader is smart enough to choose the most recent compatible > version of each dll that an application was linked with. Many of the > operating systems that libtool supports have different rules for how > to name these versions so that the runtime loader can do it's stuff. > Libtool maps the unified version number scheme it exposes to the user > onto the versioning rules for the host platform. That is why it is > okay to have libc5 and libc6 in the same directory on your Linux box. > Infact I could have several incompatible versions of libc6 in my lib > directory, and the runtime loader would choose the newest one that is > binary compatible with the version that the application was originally > linked with. Hmmmyou can do this sort of thing -- in a limited way, of course -- with appropriate naming of the dll and importlib. Recall that import libs contain the hardcoded name of the dll for which they were built. Also, there are two separate issues being discussed here: (1) how to (compile-time) link against the 'right' version of a library, and (2) how to insure that the 'right' dll is loaded at run-time. In the first case, 'right' just means the correct version that supports the necessary interface; in the second case, 'right' means the correct version compiled for the right environment -- since you can have windows-native dlls, Paul's unix-emulation-environment-based dll's (PW), cygwin dll's, UWin dll's -- all with (potentially) the same name. Since windows-dll loading is based on the executable path, and not 'LD_LIBRARY_PATH' or similar, you've got a problem. It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW LD_LIBRARY_PATH' etc. But that probably requires that you abandon dll's altogether, create your own 'so' file format, write an ld.so (ld.dll?) that will load .so's 'just like unix (tm)'. And, for this to work cleanly, such a beast would have to be written for ALL the major unix emulation environments. However, we're just concerned with cygwin, here. (I can't take credit for this idea; both Tor Lillqvist and Chris Faylor have on occaision mentioned something similar) While not abandoning the preceding idea, it IS a lot of work (and there are a lot of implementation details to work out). Although, it *will* fix point (1) *and* point (2) above. Now, you can (mostly) fix point (2: runtime loading) by the simple expedient of insuring that all dll's and exe's go into the same directory. Ugly, but much easier that the above semi-proposal. An alternative solution to point (2) is to choose a unique prefix for dll's built on each platform -- e.g. Paul's suggestion of 'cygfoo.dll' for cygwin and 'pwfoo.dll' for his PW environment. NOTE: you only need to munge the prefix of the dll itself; the import lib and/or static lib can still be 'libfoo.dll.a' or 'libfoo.a' -- because at compiletime/linktime, we *control* the library search path and are not limited by the global windows executable path. You can (mostly) fix point (1: compiletime version) by careful naming and use of import libs + careful naming and use of dll's. For instance: libpng.dll.a --> libpng3.dll.a ^^ symlink libpng30.dll.a (most recent API, corresponds to png-2.0.x) embeds the name "libpng3.dll" libpng20.dll.a (older API, corresponds to png-1.0.x) embeds the name "libpng2.dll" Programs linked against '-lpng' will be dependent at runtime on libpng3.dll. Programs linked against -lpng2 (or against '-lpng' before version 2.0.x was installed -- e.g. when libpng.dll.a --> libpng2.dll.a) will be dependent at runtime on libpng2.dll Now, suppose that the png folks release a newer version, say png-2.1.x that exposes some additional features, but is backwards compatible with png-2.0.x. Great. You build it, but create: libpng31.dll.a (embeds the name libpng31.dll.a) libpng.dll.a -> libpng31.dll.a libpng3.dll (replaces the old version (*)) Now, /usr/lib contains: libpng.dll.a -> libpng31.dll.a libpng31.dll.a libpng30.dll.a libpng20.dll.a and /usr/bin contains: libpng3.dll libpng2.dll (*) you can't play simlink games with the
Re: ranlib'ing static libraries?
On Aug 13, 2000, Assar Westerlund <[EMAIL PROTECTED]> wrote:
> * ltconfig.in: add back ranlib calls for static libraries if there
> is a ranlib
Thanks, I'm checking this in. Sorry about the delay.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Archive library breakage on standard UNIX systems with ranlib
On Sep 2, 2000, [EMAIL PROTECTED] (Michael Sokolov) wrote:
> The current libtool, both -rHEAD and -rmulti-language-branch, ever
> since 1999- 10-01 in fact, causes catastrophic breakage on standard
> UNIX systems on which archives created by ar MUST be ranlib'ed
> before ld can use them at all (at least 4.0BSD through 4.3BSD, and
> lots of others I'm sure). I have traced the breakage down to this
> change:
Please try the patch in the attached message. I'm checking it in the
libtool CVS tree right now, and I'll update libtool in the binutils
and GCC CVS trees shortly thereafter.
It seems to me that -current libtool has lost the ability to run
ranlib when creating static libraries. I added back the lines from a
previous versions, see patch at end. Is there any reason for not
calling ranlib? Not using ranlib does make static libraries not work
on some platforms, for example OpenBSD/i386. Any comments?
/assar
2000-08-13 Assar Westerlund <[EMAIL PROTECTED]>
* ltconfig.in: add back ranlib calls for static libraries if there
is a ranlib
Index: ltconfig.in
===
RCS file: /home/cvs/libtool/ltconfig.in,v
retrieving revision 1.275
diff -u -w -u -w -r1.275 ltconfig.in
--- ltconfig.in 2000/07/24 06:15:50 1.275
+++ ltconfig.in 2000/08/13 20:59:05
@@ -526,6 +528,11 @@
old_archive_cmds='$AR $AR_FLAGS $oldlib$oldobjs$old_deplibs'
old_postinstall_cmds='chmod 644 $oldlib'
old_postuninstall_cmds=
+
+if test -n "$RANLIB"; then
+ old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
+ old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
+fi
# Set sane defaults for various variables
test -z "$AR" && AR=ar
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: ultrix, cache_file and ksh
On Jul 28, 2000, Pavel Roskin <[EMAIL PROTECTED]> wrote:
> + * ltconfig.in: only load $cache_file if it's a regular file
Thanks, I'm checking this in
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: problem with nm check on recent Digital/Tru64 UNIX...
On Aug 24, 2000, Tim Mooney <[EMAIL PROTECTED]> wrote:
> If I change the egrep to
> egrep '(/dev/null| object)'
Thanks, I've just installed a variant of your patch, that had been
posted by Tom Kacvisky a *very* long time ago. Sorry about the
duplicate work :-(
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: problem with nm check on recent Digital/Tru64 UNIX...
In regard to: Re: problem with nm check on recent Digital/Tru64 UNIX...,...: >On Aug 24, 2000, Tim Mooney <[EMAIL PROTECTED]> wrote: > >> If I change the egrep to > >> egrep '(/dev/null| object)' > >Thanks, I've just installed a variant of your patch, that had been >posted by Tom Kacvisky a *very* long time ago. Sorry about the >duplicate work :-( No problem. Thanks for fixing this! Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J1, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164
Re: DLL naming conventions
On Sat, Sep 02, 2000 at 02:36:03PM -0400, Charles S. Wilson wrote: > "Gary V. Vaughan" wrote: > > > > Charles S. Wilson wrote: > > > > > > There is *something* in the windows system that gets notified that > > > myapp.exe depends on mydll.dll whenever you execute myapp.exe. This > > > *something* searches the file system according to the search path > > > described earlier in this thread, loads the dll into the executable > > > process's memeory space (rebasing the memory location if necessary), and > > > fixes up all the internal pointers to match the in-process virtual > > > memory location. > > > > > > Isn't that considered a dynamic linker? (Whether you call that > > > *something* a dynamic linker or not is really immaterial. The > > > *something* is a runtime loader, and that's what the reference above is > > > discussing) > > > > Nope. Tor is correct. The libtool versioning system assumes that the > > runtime loader is smart enough to choose the most recent compatible > > version of each dll that an application was linked with. Many of the > > operating systems that libtool supports have different rules for how > > to name these versions so that the runtime loader can do it's stuff. > > Libtool maps the unified version number scheme it exposes to the user > > onto the versioning rules for the host platform. That is why it is > > okay to have libc5 and libc6 in the same directory on your Linux box. > > Infact I could have several incompatible versions of libc6 in my lib > > directory, and the runtime loader would choose the newest one that is > > binary compatible with the version that the application was originally > > linked with. > > Hmmmyou can do this sort of thing -- in a limited way, of course -- > with appropriate naming of the dll and importlib. Recall that import > libs contain the hardcoded name of the dll for which they were built. > > Also, there are two separate issues being discussed here: (1) how to > (compile-time) link against the 'right' version of a library, and (2) > how to insure that the 'right' dll is loaded at run-time. Nah. I'm talking about (2) only. I *am* assuming that at link time the only version of a library you can link with is the one that corresponds with the header files you have installed. > In the first > case, 'right' just means the correct version that supports the necessary > interface; in the second case, 'right' means the correct version > compiled for the right environment -- since you can have windows-native > dlls, Paul's unix-emulation-environment-based dll's (PW), cygwin dll's, > UWin dll's -- all with (potentially) the same name. Okay. I probably wasn't thinking too hard about that... > Since windows-dll > loading is based on the executable path, and not 'LD_LIBRARY_PATH' or > similar, you've got a problem. Most definitely. > It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW > LD_LIBRARY_PATH' etc. But that probably requires that you abandon dll's > altogether, create your own 'so' file format, write an ld.so (ld.dll?) > that will load .so's 'just like unix (tm)'. And, for this to work > cleanly, such a beast would have to be written for ALL the major unix > emulation environments. However, we're just concerned with cygwin, > here. (I can't take credit for this idea; both Tor Lillqvist and Chris > Faylor have on occaision mentioned something similar) In an ideal world. I'd be surprised if anyone is keen enough to actually write it though. Far more likely that we can find the time to make incremental improvements and adopt some conventions that make things work a bit better... > While not abandoning the preceding idea, it IS a lot of work (and there > are a lot of implementation details to work out). Although, it *will* > fix point (1) *and* point (2) above. > > Now, you can (mostly) fix point (2: runtime loading) by the simple > expedient of insuring that all dll's and exe's go into the same > directory. Ugly, but much easier that the above semi-proposal. An > alternative solution to point (2) is to choose a unique prefix for dll's > built on each platform -- e.g. Paul's suggestion of 'cygfoo.dll' for > cygwin and 'pwfoo.dll' for his PW environment. NOTE: you only need to > munge the prefix of the dll itself; the import lib and/or static lib can > still be 'libfoo.dll.a' or 'libfoo.a' -- because at > compiletime/linktime, we *control* the library search path and are not > limited by the global windows executable path. I with you all the way so far... > You can (mostly) fix point (1: compiletime version) by careful naming > and use of import libs + careful naming and use of dll's. > > For instance: > > libpng.dll.a --> libpng3.dll.a > ^^ > symlink > > libpng30.dll.a (most recent API, corresponds to png-2.0.x) > embeds the name "libpng3.dll" > libpng20.dll.a (older API, corresponds to png-1.0.x) > embeds the name "libpng2.dll" > > Programs
Re: Archive library breakage on standard UNIX systems with ranlib
Alexandre Oliva <[EMAIL PROTECTED]> wrote: > Please try the patch in the attached message. I'm now building the tree with the current -rmulti-language-branch libtool with this patch, and it already got past building libbfd.a and libopcodes.a and linking some executables with them, so it looks good. Thanks! -- Michael Sokolov Harhan Engineering Laboratory Public Service AgentInternational Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: [EMAIL PROTECTED] (ARPA TCP/SMTP) (UUCP coming soon) P.S. Sorry for blowing my valve when I was first hit by the bug. It was just extremely frustrating when I got up Friday morning (after starting a build Thursday night) only to see it completely broken without an easy fix anywhere in sight. Then while diagnosing it, in order to try out CVS libtool, which comes without the generated files, I had to go through building and installing perl and automake. After that several libtool builds followed by tree builds. Ouch. I know that you are probably very spoiled by PCs and all that, but let me just tell you that each tree build, even with a very stripped-down tree, is several hours. Each configure run and such is anywhere from 15 to 45 minutes. All in all this bug threw me back 48 hours.
Re: DLL naming conventions
"Gary V. Vaughan" wrote: > > > > Also, there are two separate issues being discussed here: (1) how to > > (compile-time) link against the 'right' version of a library, and (2) > > how to insure that the 'right' dll is loaded at run-time. > > Nah. I'm talking about (2) only. I *am* assuming that at link time > the only version of a library you can link with is the one that > corresponds with the header files you have installed. Okay. I was just going by the example from http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html, quoted here: --- > The development links become a bit more complex. The temptation is to > place both development sets in their own subdirectories, providing: > > /usr/include/gmp1 > and > /usr/include/gmp2 > > and the development symlinks: > > libgmp1.so > and > libgmp2.so > > This causes problems for packages which expect to build against gmp. > Having to edit the make file to reflect the correct include and link names > is not a clean solution. > > Thus, for gmp-2.0.2, the includes are provided in /usr/include, and the > development link is libgmp.so. Only gmp1 need be placed in the special > locations above. But, you are right. The extra linktime libaries are only necessary if you also have the extra header files in a special directory. Since you have to edit the makefiles (and possible the source code) for 'package X' that depends on the old interface (gmp1 in this example), then you might as well specify '-lgmp1' and you don't need the symlinks. > > Since windows-dll > > loading is based on the executable path, and not 'LD_LIBRARY_PATH' or > > similar, you've got a problem. > > Most definitely. Chris argues against this in his other message. I'll reply to that point in a separt message. > > > It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW > > LD_LIBRARY_PATH' etc. But that probably requires that you abandon dll's > > altogether, create your own 'so' file format, write an ld.so (ld.dll?) > > that will load .so's 'just like unix (tm)'. And, for this to work > > cleanly, such a beast would have to be written for ALL the major unix > > emulation environments. However, we're just concerned with cygwin, > > here. (I can't take credit for this idea; both Tor Lillqvist and Chris > > Faylor have on occaision mentioned something similar) > > In an ideal world. I'd be surprised if anyone is keen enough to > actually write it though. Far more likely that we can find the time > to make incremental improvements and adopt some conventions that make > things work a bit better... I think the ld.so stuff is very ambitious. IMO, it's something to keep in mind for the next major revision of cygwin -- but then, I'm not an official spokesman. Again, IMO, 'adopting some conventions' is the way to go right now -- just like we adopted the convention that 'libfoo.dll.a' means an import lib. > > You can (mostly) fix point (1: compiletime version) by careful naming > > and use of import libs + careful naming and use of dll's. > > > > For instance: > > > > libpng.dll.a --> libpng3.dll.a > > ^^ > > symlink > > > > libpng30.dll.a (most recent API, corresponds to png-2.0.x) > > embeds the name "libpng3.dll" > > libpng20.dll.a (older API, corresponds to png-1.0.x) > > embeds the name "libpng2.dll" > > > > Programs linked against '-lpng' will be dependent at runtime on > > libpng3.dll. Programs linked against -lpng2 (or against '-lpng' before > > version 2.0.x was installed -- e.g. when libpng.dll.a --> libpng2.dll.a) > > will be dependent at runtime on libpng2.dll > > Why bother with the symlinks? You can't link against -lpng2 unless > you have matching headers, and presumably you upgraded those when you > installed libpng3.dll. > > My proposal was to start with this: > > libpng.dll.a embeds libpng2.dll > > and we keep libpng1.dll around for the applications that were > linked against interface 1. > > when we install png-2.0, which implements a new interface that is not > compatible with libpng2.dll, we install: > > a replacement libpng.dll.a that embeds libpng3.dll > libpng3.dll > > and we keep libpng2.dll around for the applications that were > linked against interface 2. > > and we keep libpng1.dll around for the applications that were > linked against interface 1. You are (mostly) right. The symlinks are not really necessary -- but keeping libpng20.dll.a is a good idea (assuming you also kept the 2.0.x headers around, and put them in /usr/include/png2/. The symlink buys you ease of installation for the implib. Suppose you had 1.0.x installed, so libpng.dll.a embeds libpng2.dll. Then, you install 2.0.x. First, you need to rename libpng.dll.a to libpng2.dll.a, and then install the new implib as libpng.dll.a. With symlinks, none of that is necessary -- just install the new implib as libpng3
