|
From: Earnie B. <ea...@us...> - 2006-03-27 22:42:36
|
Quoting Michael Gerdau <mg...@te...>: >> I was thinking of the scenario wher a user downloads the prebuilt >> binary tarballs, and unpacks those in place of an existing installation. >> Such a user won't be using Makefiles, to perform an upgrade. > > That wouldn't be a problem though because of the order in which > ld tries to resolve libnames. > > According to ld's info file we have the following order: > libxxx.dll.a > xxx.dll.a > libxxx.a > cygxxx.dll (*) > libxxx.dll > xxx.dll > > So even if we have an old installation all that would happen is > we have obsolete files named libxxx.a and current libxxx.dll.a > ld would choose the newer (and correct) version. > > Basically it would be a waste of diskspace. But then it seems > pretty simple to create a shellscript to remove all such dublicates. > And a bunch of confusion to cloud up the email list. Say libkernel.a is now delivered as libkernel.dll.a. So now the user sees static library libkernel.a and dynamic import library libkernel.dll.a which is just plain wrong. So now we get the questions about why the static version still requires the DLL. Let's not forget about the bits in GCC or BINUTILS and LIBTOOL that look for these system files with the .a extension to do special things. How will these be affected? What changes will need to take place with the tools? The benefit here isn't worth the time I've taken with this email. Earnie Boyd http://shop.siebunlimited.com |