From: Marcio H. <sem...@it...> - 2006-03-20 10:32:53
|
I want to suggest a naming rule for gcc libraries: static library -> libNAME.a dynamic library -> libNAME.dll.a where: - static library is an archive with a set of routines/functions. - dynamic library will link routine/function calls to NAME.dll file. a bad example: -libopengl32.a will link to opengl32.dll and have a static library name. |
From: Marcio H. <sem...@it...> - 2006-03-20 10:57:35
|
I want to suggest a naming rule for gcc libraries: static library -> libNAME.a dynamic library -> libNAME.dll.a where: - static library is an archive with a set of routines/functions. - dynamic library will link routine/function calls to NAME.dll file. a bad example: -libopengl32.a will link to opengl32.dll and have a static library name. |
From: Michael G. <mg...@te...> - 2006-03-20 13:46:29
|
> I want to suggest a naming rule for gcc libraries: >=20 > static library -> libNAME.a > dynamic library -> libNAME.dll.a >=20 > where: > - static library is an archive with a set of routines/functions. > - dynamic library will link routine/function calls to NAME.dll file. >=20 > a bad example: > -libopengl32.a will link to opengl32.dll and have a static library name. Just for me to understand what you mean: When you write 'dynamic library' you actually mean 'import library' Right ? And while I'm at it: What is the rationale behind this proposal ? Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Julien L. <ju...@fa...> - 2006-03-22 13:10:17
|
On 20/03/2006 14:45, Michael Gerdau quoted Marcio Hermes: >> I want to suggest a naming rule for gcc libraries: >> >> static library -> libNAME.a >> dynamic library -> libNAME.dll.a >> >> where: >> - static library is an archive with a set of routines/functions. >> - dynamic library will link routine/function calls to NAME.dll file. >> >> a bad example: >> -libopengl32.a will link to opengl32.dll and have a static library name. > > Just for me to understand what you mean: > When you write 'dynamic library' you actually mean 'import library' I support this idea of having static libraries '.a' and import libraries as '.dll.a' My system is currently set up this way, and I haven't had issues with it. > And while I'm at it: > What is the rationale behind this proposal ? First, developper friendliness, by looking at an extension, we know right away if it's an import library or a static library. Geeks like me assign different icons to each extension ;-) Also, this doesn't affect gcc's linking order, it inforces the difference between static and shared, and actually gives more priority to linking with a import library. Examples of search orders (`gcc -Wl,--verbose foo.c') gcc.exe (GCC) 3.4.5 (mingw special): - libfoo.dll.a - foo.dll.a - libfoo.a - libfoo.dll - foo.dll - libfoo.a (duplicate, shouldn't this be 'foo.a' ???) Because of this, we can ensure that the program will be linked against a dll if using -lfoo.dll: - libfoo.dll.dll.a - foo.dll.dll.a - libfoo.dll.a (the one we want) - libfoo.dll.dll - foo.dll.dll The naming of .dll.a and .a is also a convention that is respected by more and more packages because of the use of libtool in such packages. When creating dlls, libtool places the dll in /bin, and creates '.dll.a', '.a' and '.la' in /lib Even if we're not to use libtool for w32api and mingw-runtime; we could respect libtool's defaults in naming. The only caveat I found is that the specs file needs to be reviewed if using `gcc -Wl,-dn' or `gcc -Wl,-dy' (ie, linking only to static/shared libraries) The fix is simple: change every occurance of -lfoo to -lfoo.dll if the library had been renamed (eg: libkernel.a to libkernel.dll.a) Julien |
From: Earnie B. <ea...@us...> - 2006-03-22 16:09:14
|
Quoting Julien Lecomte <ju...@fa...>: > > The only caveat I found is that the specs file needs to be reviewed > if using `gcc -Wl,-dn' or `gcc -Wl,-dy' (ie, linking only to > static/shared libraries) > The fix is simple: change every occurance of -lfoo to -lfoo.dll if > the library had been renamed (eg: libkernel.a to libkernel.dll.a) > The system libraries are always a .dll; one can use ``nm'' to discover if the library is an import library or static library without too much effort. The .dll.a extention was added at a later date than the start of MinGW and we've just not taken an initiative to change the name of the libraries. Changing the name of the libraries would also mean that we would need to remove existing libraries with the old name when someone performs an upgrade. That isn't really accomplished easily with a tarball so we have decided to leave the name the with just a .a extention. Earnie Boyd http://shop.siebunlimited.com |
From: Keith M. <kei...@to...> - 2006-03-23 14:41:13
|
Earnie Boyd wrote, quoting Julien Lecomte: >> The only caveat I found is that the specs file needs to be reviewed >> if using `gcc -Wl,-dn' or `gcc -Wl,-dy' (ie, linking only to >> static/shared libraries) >> The fix is simple: change every occurance of -lfoo to -lfoo.dll if >> the library had been renamed (eg: libkernel.a to libkernel.dll.a) > > The system libraries are always a .dll; one can use ``nm'' to discover > if the library is an import library or static library without too much > effort. The .dll.a extention was added at a later date than the start > of MinGW and we've just not taken an initiative to change the name of > the libraries. Changing the name of the libraries would also mean that > we would need to remove existing libraries with the old name when > someone performs an upgrade. That isn't really accomplished easily > with a tarball so we have decided to leave the name the with just a .a > extention. Something of a cop-out, perhaps, for surely it should be possible to automate the entire process with a script -- would you care to provide and maintain one, Julien? While it would certainly be nice to adopt a convention, where static libraries are named `libNAME.a' and import libraries are distinguished by being named `libNAME.dll.a', this can never be more than simply a convention, rather than a hard and fast rule. As Julien has noted, MinGW is already well capable of supporting such a convention. However, Earnie has touched on a real problem, arising from the need for us to continue to operate within a legacy infrastructure. The problem with providing a script to automate the renaming process is that the onus to invoke it appropriately lies entirely with the user; it is completely beyond our control. I agree with Earnie; it is best for us to retain the legacy infrastructure. If any user wishes to adopt an alternative convention, they are free to do so, AT THEIR OWN RISK, and go ahead and rename their installed libraries as Julien has suggested. If Julien, or anyone else, would like to provide a script to automate the renaming procedure, then that is fine; however, I would be most reluctant to support its use, as an official MinGW installation option. Regards, Keith. |
From: Julien L. <ju...@fa...> - 2006-03-25 11:42:56
|
On 23/03/2006 15:38, Keith MARSHALL wrote: > Earnie Boyd wrote, quoting Julien Lecomte: >>> The only caveat I found is that the specs file needs to be reviewed >>> if using `gcc -Wl,-dn' or `gcc -Wl,-dy' (ie, linking only to >>> static/shared libraries) >>> The fix is simple: change every occurence of -lfoo to -lfoo.dll if >>> the library had been renamed (eg: libkernel.a to libkernel.dll.a) >> The system libraries are always a .dll; one can use ``nm'' to discover >> if the library is an import library or static library without too much >> effort. The .dll.a extention was added at a later date than the start >> of MinGW and we've just not taken an initiative to change the name of >> the libraries. >> Changing the name of the libraries would also mean that >> we would need to remove existing libraries with the old name when >> someone performs an upgrade. I don't think their is a *need* to remove the existing libraries but it would be *highly* *recommeded*. >> That isn't really accomplished easily >> with a tarball so we have decided to leave the name the with just a .a >> extension. > > Something of a cop-out, perhaps, for surely it should be possible to > automate the entire process with a script -- would you care to provide > and maintain one, Julien? Why a script ? Shouldn't it all be done in the makefiles ? Just by modifying the configure script, we can add an option such as --with-new-naming (or --with-libtool-naming) that would take care of building and installing of whichever the user wants. This is also perfect to address the following issues: - keeping legacy - not using libtool - not using automake (I'm taking in account Keith's POV on automake) Julien |
From: Keith M. <kei...@to...> - 2006-03-27 12:03:49
|
Julien Lecomte wrote, quoting me: > I don't think their [sic] is a *need* to remove the existing libraries > but it would be *highly* *recommeded*. > >> Quoting Earnie Boyd: >>> That isn't really accomplished easily >>> with a tarball so we have decided to leave the name the with just a .a >>> extension. >> >> Something of a cop-out, perhaps, for surely it should be possible to >> automate the entire process with a script -- would you care to provide >> and maintain one, Julien? > > Why a script ? Shouldn't it all be done in the makefiles ? 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. > Just by modifying the configure script, we can add an option such as > --with-new-naming (or --with-libtool-naming) that would take care of > building and installing of whichever the user wants. Again, this won't help for a upgrade based on binary tarballs. What would be required is:-- - Tarballs are built, exclusively with legacy library file names. - User downloads and unpacks these, overwriting similarly named files in his/her existing installation. - User runs script, removing any import libraries with new names, for which a legacy named replacement is present, and renames the legacy named replacement with the new name. Note that it isn't acceptable to erase the original installation, before progressing an upgrade; that could remove more than the upgrade will replace, particularly if the user is in the habit of installing mingwPORTs, or other additional packages, into the MinGW tree, (which *is* the default for mingwPORTs). Regards, Keith. |
From: Julien L. <ju...@fa...> - 2006-03-27 15:38:57
|
On 27/03/2006 13:57, Keith MARSHALL wrote: > Julien Lecomte wrote, quoting me: >> I don't think their [sic] is a *need* to remove the existing libraries >> but it would be *highly* *recommeded*. >> >>> Quoting Earnie Boyd: >>>> That isn't really accomplished easily >>>> with a tarball so we have decided to leave the name the with just a .a > >>>> extension. >>> Something of a cop-out, perhaps, for surely it should be possible to >>> automate the entire process with a script -- would you care to provide >>> and maintain one, Julien? >> Why a script ? Shouldn't it all be done in the makefiles ? > > I was thinking of the scenario wher [sic] 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. In that case, we can't rely on the user having a mSys installation. Such a script should either be a batch script (ugh !) or run from the installer. > >> Just by modifying the configure script, we can add an option such as >> --with-new-naming (or --with-libtool-naming) that would take care of >> building and installing of whichever the user wants. > > Again, this won't help for a upgrade based on binary tarballs. > > What would be required is:-- > > - Tarballs are built, exclusively with legacy library file names. > - User downloads and unpacks these, overwriting similarly named > files in his/her existing installation. > - User runs script, removing any import libraries with new names, > for which a legacy named replacement is present, and renames the > legacy named replacement with the new name. > Didn't we settle on the fact that using a new naming convention should be reserved to 'power users' and be more or less officially unsupported ? I think we should only let the people who build from sources have the option to use the new naming scheme for now. If the new naming proves to be stable and better, then in a second stage provide the script for all users and make the transition. I'll nevertheless see to create a script, in sh and bat format, and also see to offer a patch of configure/makefile; it'll take my mind off pipes, pty's and terminals for a while. I'll also pre-test it on cygwin, and in a cross-compiler environment. > Note that it isn't acceptable to erase the original installation, > before progressing an upgrade; that could remove more than the > upgrade will replace, particularly if the user is in the habit of > installing mingwPORTs, or other additional packages, into the > MinGW tree, (which *is* the default for mingwPORTs). Oh, so we can't rely on 'format c:' ? Cheers, Julien |
From: Keith M. <kei...@to...> - 2006-03-27 16:18:55
|
Julien Lecomte wrote, quoting me: >> I was thinking of the scenario wher [sic] ... Okay. Okay. Did I really miss the final `e' off `where'? It's a typo, obviously... :-) >> ... 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. > > In that case, we can't rely on the user having a mSys installation. Such > a script should either be a batch script (ugh !) or run from the installer. Yep. And since not everyone wants to use the installer, the only real option is a cmd.exe batch script; (couldn't get much yukier, really). >>> Just by modifying the configure script, we can add an option such as >>> --with-new-naming (or --with-libtool-naming) that would take care of >>> building and installing of whichever the user wants. >> >> Again, this won't help for a upgrade based on binary tarballs. >> >> What would be required is:-- >> >> - Tarballs are built, exclusively with legacy library file names. >> - User downloads and unpacks these, overwriting similarly named >> files in his/her existing installation. >> - User runs script, removing any import libraries with new names, >> for which a legacy named replacement is present, and renames the >> legacy named replacement with the new name. > > Didn't we settle on the fact that using a new naming convention should > be reserved to 'power users' and be more or less officially unsupported ? I didn't realise we had actually reached any final consensus. > I think we should only let the people who build from sources have the > option to use the new naming scheme for now. If the new naming proves to > be stable and better, then in a second stage provide the script for all > users and make the transition. Hmm. I wonder how many will do that? I've only ever done it for the i586-mingw32-gcc on my Linux box; for the native toolchain on Win2K, I'm happy to use the binary downloads from the SF mirrors. > I'll nevertheless see to create a script, in sh and bat format, and also > see to offer a patch of configure/makefile; it'll take my mind off > pipes, pty's and terminals for a while. I'll also pre-test it on cygwin, > and in a cross-compiler environment. It'll be interesting to see what you can conjure up. >> Note that it isn't acceptable to erase the original installation, >> before progressing an upgrade; that could remove more than the >> upgrade will replace, particularly if the user is in the habit of >> installing mingwPORTs, or other additional packages, into the >> MinGW tree, (which *is* the default for mingwPORTs). > > Oh, so we can't rely on 'format c:' ? ROFL! Oh, *I* wouldn't even bother with that! Just bung in whatever Linux Installer DVD you fancy, reboot, select the option to "Delete all existing partitions", and install using all of /dev/hda. :-) Cheers, Keith. |
From: Julien L. <ju...@fa...> - 2006-03-27 17:03:56
|
On 27/03/2006 18:18, Keith MARSHALL wrote: > Julien Lecomte wrote, quoting me: >>> ... 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. >> In that case, we can't rely on the user having a mSys installation. Such > >> a script should either be a batch script (ugh !) or run from the > installer. > > Yep. And since not everyone wants to use the installer, the only > real option is a cmd.exe batch script; (couldn't get much yukier, > really). I've noticed that any change in any project often requires the worst case scenario ;-) >> Didn't we settle on the fact that using a new naming convention should >> be reserved to 'power users' and be more or less officially unsupported > ? > > I didn't realize we had actually reached any final consensus. Quoting your email of March 23: "I agree with Earnie; it is best for us to retain the legacy infrastructure. If any user wishes to adopt an alternative convention, they are free to do so, AT THEIR OWN RISK, [...] however, I would be most reluctant to support its use, as an official MinGW installation option." Maybe I extrapolated your words, but it seemed clear to me that brutally changing everything for everyone was not a 'good thing' (tm). Anyway, I wasn't in disagreement (for once ?) with Earnie's or your POV. The changes that the .dll.a naming convention presents are small in benefit compared to what it could break. That's why I support the fact there should be a unsupported staging period. If all goes well, then maybe, we could make it official in 6 months, a year, or even more; provided that at least others have tested this naming scheme. Julien |
From: Michael G. <mg...@te...> - 2006-03-27 17:11:29
|
> 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. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
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 |