Re[2]: Very reason for not using gcc to link shared libraries?
Hello Alexandre, Alexandre Oliva <[EMAIL PROTECTED]> wrote: AO> On Mar 29, 2000, Paul Sokolovsky <[EMAIL PROTECTED]> wrote: >> But what was the problem with gcc in the first place? AO> The problem was that, since the compiler would implicitly link in AO> certain libraries, libtool couldn't apply whatever mechanisms it uses AO> to verify whether the libraries are shared or not, where appropriate. AO> And this is indeed necessary on some platforms. Aha, keyword is "some platforms". AO> Fortunately, thanks mainly to Ossama Othman, this will all be fixed in AO> libtool 1.5, which is under development in the libtool multi-language Oh, it seem it'll be a long time ;-) Or maybe I misunderstand version numbering? What I have from MAIN CVS written 1.3d in NEWS. What will be next - 1.4 made from MAIN CVS? And next - 1.5 from ML CVS? Or 1.5 will be released when ML branch will be merged with main? Anyway, if I'm interested in developing libtool, am I suggested to look, or maybe even base, on ML branch? AO> branch. Hopefully, when that work is completed, we'll always be able AO> to use GCC to link libraries and programs, since libtool will learn AO> which objects and libraries GCC links in, and will behave as AO> appropriate. That's nice. What I'd like to do now is try to make up-to-seamless support for win32 dlls. I'm glad to know that there's no problem with using gcc to link on *that platform*. AO> -- AO> Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/ -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Very reason for not using gcc to link shared libraries?
Greetings Libtool community, I'm newcomer hoping to get some enlightment on libtool design principles, with motivation to be helpful in making libtool support win32 dlls sanely. I would like to ask why libtool in the first place was made to use ld to link libraries and not gcc? Only hint in documentation is that using compiler will "lead to problems with inter-library dependencies". From the first thought, it seems strange - it should be in opposite, save little burden on tracking defaultly-linked libraries. As far as I see, using g++ to seamlessly link C++ is what currently become being done to overcome those C++ linking problems. But what was the problem with gcc in the first place? Thank you, -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[4]: Very reason for not using gcc to link shared libraries?
Hello Alexandre, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> That's nice. What I'd like to do now is try to make up-to-seamless >> support for win32 dlls. I'm glad to know that there's no problem >> with using gcc to link on *that platform*. AO> I'm sure Gary will tell you how impossible that is to achieve, because AO> of the brain-damaged way in which DLLs were designed on MS-Windows. Yes, we already had little talk on this. But that's what ignorant newcomers are good for - they don't know precise level of impossibility ;-) AO> At least, I think I've already convinced him of that. :-) Well, then I'll try to convince him of the opposite ;-) Precisely, my motivating ideas are following: - It's far more possible to build win32 dlls in sane way than usually percieved by gnu, and even gnu-win32 people (well, according to my persception ;-) ) - When there're some problems, it should be taken care to communicate them to user in sensible way (even for non-win32 ones) and provide guidelines (ideally, formal steps) how to resolve them. AO> -- AO> Alexandre OlivaEnjoy Guaraná, see http://www.ic.unicamp.br/~oliva/ -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[4]: Very reason for not using gcc to link shared libraries?
Hello Gary, Gary V. Vaughan <[EMAIL PROTECTED]> wrote: GVV> On Wed, Mar 29, 2000 at 09:59:07AM -0300, Alexandre Oliva wrote: >> On Mar 29, 2000, Paul Sokolovsky <[EMAIL PROTECTED]> wrote: >> > What I'd like to do now is try to make up-to-seamless >> > support for win32 dlls. GVV> If you only care about win32, life becomes much easier. In fact you GVV> probably shouldn't even try to jump through libtool's hoops. No, no of course I care about seamless support on any platform, *including win32*. I'm quite happy build dlls in ad hoc manner, but I really got an idea that I want grab libtoolized library for *nix and build it automagically for win32 ;-) GVV> Libtool absolutely must provide the same interface to the developer GVV> for all platforms, and it would be unfair to cater to the lowest GVV> common denominator (windows) when every other platform we support has GVV> much, much more functionality. That we have got it to work as well GVV> as it does has involved much sweat and tears! Yes, the same interface is a presupposition. But why you think that it's impossible with windows? Well, why you think windows is least common denominator? I'll try to challenge such view in reply to your original mail. >> > I'm glad to know that there's no problem >> > with using gcc to link on *that platform*. >> I'm sure Gary will tell you how impossible that is to achieve, because >> of the brain-damaged way in which DLLs were designed on MS-Windows. GVV> Well, with DJ Delories binutils mods, all of the dlltool nastiness has GVV> gone away, so you *can* use just gcc to link a dll. Unfortunately, support made by DJ is underfunctional, and can be used only in special cases (namely, when building dlls is explicitly supported by package, but as you understand, I care about building dlls even when they're not supported ;-) ) GVV> Unfortunately, GVV> this version of binutils is hard to come by, so for the moment we are GVV> stuck with libtool and a five stage link =(O| Not quite true. While cygwin is of course fashion provider in gnu-win32 world, thanks god, it's not the only gnu-win32 target. Mingw32 now has aforementioned gcc -shared support. And as I told, it currently far from being ruling. >> At least, I think I've already convinced him of that. :-) GVV> `Impossible' is bit too strong. I still think that it will be GVV> possible to create shared libraries on windows which behave a bit like GVV> elf shared libraries in the civilised world, but it will involve GVV> *alot* of deep magic. The payback is barely worth the huge effort (it GVV> would almost be easier to design a new binary format and loading GVV> mechanism), and there is so much other good work to be done in other GVV> areas of libtool that it is slipping ever lower down my todo list. I greatly agree with you. It would be much easier just port ld.so from Linux and forget all the gore. BUT - that will mean incompatibility with native applications, what is not acceptable. So, I'd prefer to put deep magic in libtool to support dlls. And yes, there will be needed alot of such magic, but imho little less than currently in ;-) . GVV> Cheers, GVV> Gary. -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[4]: State of win32 dll support in libtool at CVS
is for cygwin (I know, both problems are fixed in CVS) but DLL is finally built! Resume: if libtool wouldn't care too much about me, I'd get it from the first time. If I couldn't get it, I'd get fairly understandable linker message about underfined symbols. If libtool were smart enough, it would suggest me what to do next. *After* there's problem. Not saving me from the problem *before it might happen*. Support, not deny. Well, I talk too much. That's not what I came for. I would like to invite you take a look at my a2dll script, http://www.is.lg.ua/~paul/devel/binutils.html . I appreciate your comments. GVV> Cheers, GVV> Gary. -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Proposal: globalizing 'libtool' creation method
Hello libtool, I'm currently working on implementing full (to the extent possible) support for win32 dlls. Since ways in which I'm trying to achieve this differ substantially from current libtool's approach and hacking 100k shell scripts is little fun, I prototype it from scratch in Python. Currently, I'm doing it in the following way: I configured libtool once, pasted config variables from it to my Python script and did proper for Python quoting of values. Then, for each package, I configure it as usually, and then replace libtool with mine. For the early hacking it's ok, but to test it realistically and use for production, I need way to convert libtool configuration automatically. I can write srcipt which will filter config section of old libtool, then re-quote single-line values in doublequotes, multiline in tripled doublequotes, as Python requires. However, it will be totally adhoc script, which yet should be run manually. Rather, I'd invest my time in what I'd call generalizing template approach of libtool creation. The current approach to create libtool is itself adhoc: 1. There're to versions of libtool template, one in sh and one in C (dummy). 2. Name of template to use is passed as argument to ltconfig. 3. Ltconfig in adhoc way checks what template of the two possible languages passed, quotes variable in adhoc way for each. 4. Then, it either appends interim (full!) shell template or going to compile C. Instead, I propose following: 1. There's *single* template for libtool. 2. It consists of several chunks, each of which represent template for full future libtool. 3. Each chunk has header which specifies: a) metachar-enabled list of target triples for which this chunk implements libtool b) arbitrary expression which must evaluate to true for this chunk to be selected 4. Rest of chunk is text of specific libtool, with usual template variables @VAR@. 5. Following procedure to be used for cretaing libtool: a) libtool performs usual actions to infer libtool configuration b) libtool template is searched for first chunk matching target and for which enabling expression evaluated to true. c) on the given chunk substitution performed, replacing substrings '@VAR@' with value of variable VAR. d) libtool is ready Benefits: 1. CLear and concise procedure 2. Easy to add new libtools implementation written for any specific platform and in any language. 3. Even if 2 is not apply, then at least easy to hack and experiment with new libtool implementations. Does this sound sane? -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Status of availability of features which allow correct and seamless support of DLLs in current GNU-Win32 releases
Hello libtool, This is a forwarded message From: Paul Sokolovsky To: DJ Delorie Date: Saturday, April 29, 2000, 1:43:49 PM Subject: Question about binutils of cygwin 1.1.0 ===8<==Original message text=== Hello DJ, O, I used to ask Mumit Khan why he distributes such outdated, 19990818 binutils for mingw32, and got answer that there's bad attitudes of binutils maintainers towards pe frontend. Now, when official Cygnus release contains the same, I see that's true... Well, what I want to ask whether cygwin binutils are built from Mumit's sources, i.e. contain additional (required!) patches. My tests shows that yes. Asking just to be sure. Best regards, Paul ===8<===End of original message text=== This is a forwarded message From: DJ Delorie To: Paul Sokolovsky Date: Saturday, April 29, 2000, 3:43:12 PM Subject: Question about binutils of cygwin 1.1.0 ===8<==Original message text=== The binutils and gcc on sourceware *are* from Mumit. ===8<===End of original message text=== With this I would like to confirm that current releases of major gnu-win32 targets: - Cygwin 1.1.0 - Mingw32 2.95.2-1 contain support, in binutils and gcc, for the following features crucial for easy and robust creation of dynamically-linked libraries (DLLs): - One-pass link supported directly by ld, with standard -shared option enabling it. - Distinguishing between code and data symbols both when creating module definition file (def) from set of object files and when creating import library (implib) from def (as well as for one-step process, of course). While ld -shared brings great convenience to building of dlls, it doesn't offer anything new technologically - all its functionality was supported before by dllwrap. However, proper handling of data symbols is presupposition to both robust procedure of making some code dll-aware and correct working of resulting code. Please see following links for more information: http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00719.html http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00730.html http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00734.html http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00763.html http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00779.html http://sourceware.cygnus.com/ml/cygwin/1999-08/msg00781.html Having said that, it should be noted that both novelties have misfeatures which may require workarounds, sometimes human-attention-requiring. I'll try to summarize ones I'm aware of: ld -shared -- 1. ld is quite smart (thanks, DJ): when object files it links do not contain explicit dllexported symbols, it automagically exports all symbols, as if --export-all option were given. The problem here is that such case it doesn't export any data symbols - neither with this automagical feature, nor with explicit --export-all. Reason behind is understandable - using data symbols requires additional coping with them after dll was created, so let's pretend they don't exist at all. Failure here is that such policy disallow coping with data symbols *at all*. What surprises me is that it's DJ Delorie who did it that way ( ;-) ). I was able to come up with following workaround: create def with dlltool and then feed it to ld -shared. However, ld when given def with ordinals (the way dlltool produces it), makes broken dlls. So, it needs to produce def, filter it off ordinals, and then give it to ld. 2. There were reported pathological cases when ld -shared slower than dlltool %) . Def/implib creation --- 1. I noticed that dlltool --export-all marks symbols from assembly code as data, even though some are code. Here, I am to be blamed: patch to classify symbols in --export-all case was submitted by me. However, it is two-lines-long: I just take "is_function" flag from bfd structure for symbol. So, it seems that bfd sets that flag only for symbols having their type set by .def assembly directive accordingly. Workaround would be to delete DATA option from def manually. 2. Dlltool does not support symbol aliasing option (onename=othername in def), allowing symbol imported from dll to be seen by application with the other name. That's mostly advanced option, which may be required for example to create dll proxying other dll. Available workaround is to supply symbol from dll the DATA option, so the application will get pointer to the symbol contents in dll as _im__. Also, patch to support aliasing feature wa sposted to mingw32 maillist. 3. Last note about creation of correct defs from existing (binary-only) dll. I've patched Anders Norlander's pexports program for that, available from http://www.is.lg.ua/~paul/devel/binutils.html . It should be noted that task to classify symbols from binary file by code/data can be done only heuristically. I used one simple that symbol
Re[2]: Status of availability of features which allow correct and seamless support of DLLs in current GNU-Win32 releases
Hello Ian, Monday, May 01, 2000, 10:39:46 PM, you wrote: ILT> O, I used to ask Mumit Khan why he distributes such outdated, ILT>19990818 binutils for mingw32, and got answer that there's bad ILT>attitudes of binutils maintainers towards pe frontend. Now, when ILT>official Cygnus release contains the same, I see that's true... ILT> I don't think that's a fair characterization of the situation. Sorry, I appologize, it was not intended as any characterization at all. This is a forwarded message From: Paul Sokolovsky <[EMAIL PROTECTED]> To: Mumit Khan <[EMAIL PROTECTED]> Date: Monday, May 01, 2000, 11:13:44 AM Subject: [mingw] Status of availability of features which allow correct and seamless support of DLLs in current GNU-Win32 releases ===8<==Original message text=== Hello Mumit, Sunday, April 30, 2000, 10:43:40 PM, you wrote: MK> On Sun, 30 Apr 2000, Paul Sokolovsky wrote: >> O, I used to ask Mumit Khan why he distributes such outdated, >> 19990818 binutils for mingw32, and got answer that there's bad >> attitudes of binutils maintainers towards pe frontend. Now, when >> official Cygnus release contains the same, I see that's true... MK> I take exception to this statement. The binutils maintainers may MK> not be PE hackers, and it's fair to say that most of the gurus MK> tend not to pay much attention PE as to say ELF, but saying that MK> they have "bad attitude" is entirely unfair. If I ever said anything MK> that may have suggested this "bad attitude", I certainly didn't mean MK> it in a negative way and I apologize for any misunderstanding. Sorry, of course that term is not based on anything I heard from you. Nor it carries any sense, or grounded on anything, except my personal passive vexation that even cygwin uses old binutils snapshot, stuffed into two words of private email which was not supposed to be forwarded to public. I cannot talk reasonably about something being wrong about PE with binutils simply because I never tried to submit patch directly, so cannot say that something was rejected. Moreover, look at binutils maillist shows that, if maintainers allocate theit time proportionally to requests, that PE really don't get top priority. Some little thought also makes to understand why Cygwin 1.1.0 contains your snapshot of binutils - it is very nice that first official net release (not beta) includes stable binutils, which testing with mingw32 for several months showed their liveness. MK> I for one have not submmitted some of the patches that may fix MK> problems in the PE target, and certainly have not lobbied as hard MK> as I could have to get some of the queued changes in. My usual MK> excuse is the lack of time. Please let's not point fingers, it's MK> not productive. Spirit of my message was totally optimistic: imho, never support for Win32-specific fetures in gnu-win32 was so functional and robust. Just mere listing of known problems I tried to make shows that: all they quite minor and doesn't require immediate attention to fix. But indeed, engaged in that, I forget to thank people who made that possible: Cygnus people who started all that, and specially binutils maintainers, fruits of whose work now used not only by cygwin, but all other gnu-win32 targets, DJ Delorie, who made ld -shared support for dlls, and Mumit Khan who paid attention to code/data problem and finished his long work on supporting dllexport/dllimport support in gcc, as well as all people who tested and submitted bugreports to the tools. Current gcc/binutils combination gives me only pleasant surprises. For example, I converted project which used one big dll into set of interdependent dlls. For this, it requires some magic in the headers, which hard to do right from the beginning. But gcc was quite friendly with such situation, warning me about dllimport/dllexport conflicts and selecting right one (dllexport) to go. Just couple days ago I hacked libtool into supporting interdependent dlls with it, and expected that my another hack will allow to build one dll from the interdepndent set. I was very surpised when I got two. Investigation showed that if gcc sees dllimported decalration of some var, and then definition of that var, it discards dllimported attribute, which considerably simplifies aforementioned header magic. Of course, it works only if dll built from single source, but in my personal case it really helpful, allowing me to finish with tracking dependencies first, before going to hack automake to support general case of interdependentness. MK> Regards, MK> Mumit Best regards, Paulmailto:[EMAIL PROTECTED] ===8<===End of original message text=== ILT> Ian Best regards, Paulmailto:[EMAIL PROTECTED]
PATCH: handle lt_dlopen(0) for win32
Hello libtool,
libltdl currently segfaults on lt_dlopen(0). Patch below fixes that by
implementing dlopening self:
2000-05-03 Paul Sokolovsky <[EMAIL PROTECTED]>
* ltdl.c: support lt_dlopen(0) for win32
--- ltdl.c Tue Mar 28 19:22:06 2000
+++ E:\Projects\libtool-hack\libltdl\ltdl.c Wed May 3 18:26:14 2000
@@ -457,7 +457,16 @@ sys_wll_open (loader_data, filename)
lt_dlhandle cur;
lt_module_t module;
char *searchname = 0;
- char *ext = strrchr(filename, '.');
+ char *ext;
+char self_name_buf[MAX_PATH];
+
+if (!filename) {
+ /* Get the name of main module */
+ *self_name_buf = 0;
+ GetModuleFileName(NULL, self_name_buf, sizeof(self_name_buf));
+filename = ext = self_name_buf;
+}
+ else ext = strrchr(filename, '.');
if (ext) {
/* FILENAME already has an extension. */
Best regards,
Paul mailto:[EMAIL PROTECTED]
Re[4]: Some DLL-related changes
Hello Alexandre, Friday, July 28, 2000, 4:41:52 AM, you wrote: AO> On Jul 27, 2000, Paul Sokolovsky <[EMAIL PROTECTED]> wrote: >>>> - allow_undefined_flag=unsupported >>>> + allow_undefined_flag='-Dundefined' AO>> I'm pretty sure this is not enough, at least for some older versions AO>> of Cygwin. >> Older versions of cygwin were betas and long've been gone. AO> For you, maybe. There are still people using them, and unless we have AO> good reason to break them, we shouldn't. I don't think we have a good AO> reason. AO> Besides, are you really sure -Dundefined also works on all versions of AO> mingw? -Dundefined does no magic - it just defines (unused) compiler macro. Reasoning is that I wanted turn off allow_undefined_flag=unsupported behaviour, while still allowing users to see if allow-undefined was specified. >> That's not true. That's dll client executables cannot be built >> without __declspec - *in some cases*. Dlls themselves are always built >> (unless there're several mutually dependent ones). I proved that to >> Gary. Well, I showed him ;-) AO> I see. This is news to me. Good news. But how about data symbols AO> exported from the library? There's never problem with *exporting* anything, only *importing* has. AO> If DLLs don't work just like on regular AO> systems, there's little point (IMO) in creating the library, since AO> people won't be able to link with them. They will! But, *maybe*, after some additional work. AO> Is there any way we can tell AO> whether the library exports any data symbols, by looking at object AO> files and its dependencies? Yes, that's how my a2dll script works, http://www.is.lg.ua/~paul/devel/a2dll.html AO>> Wrong. LN_S should already be `cp' on systems that don't support AO>> soft-linking. If this isn't the case, that's what you want to fix. >> And I use mingw32-hosted gcc currently, so while pw32 has >> symlinks, gcc/binutils don't understand them ;-) AO> I see. So probably the way to go is to extend the test of soft links AO> to check whether the tool-chain can understand them. No! That's bug of my system! Soon it'll vanish forever, so there's no need to drag workaround all along. AO>> Wrong, this breaks builds on FAT file-systems. >> Again not true. It doesn't break building on FAT systems. AO> I'm talking about plain old FAT, not FAT32 or such extensions. So do I. In Windows 95 of year 1995 MS introduced so-called 'vfat' which completely backward-compatible with fat but allows long names. Since win95 is the very first complete win32 system, that any win32 system support sane filenames. Btw, it's also long-standing stereotype that there's some problems with naming files on win9x systems. Nescape up to 4.7 was used to screw up downloaded filenames by replacing all but the last dot to underscores. Fortunately, they fixed that in 4.72 ;-) >> We won't consider crosscompiling from djgpp under bare dos to >> gnu-win32 or gnu-linux, will we? ;-) AO> Why not? What's wrong with someone using DOS for real development? :-)/2 If someone so bright, I hope he'll have an idea of putting duty of converting filenames to representation acceptable by that dos to his runtime library and not application programs ;-P AO> No, it is MS-Windows's DLL model that's totally against libtool grand AO> idea. The developer must modify header files to be able to link with AO> DLLs. No, only *may need*. AO> That's why libtool requires a special macro for the developer AO> to tell libtool the package has been properly adapted to support DLLs. I don't see how that macro saves developer from modifying headers. Instead, what it does is turns "may need" to "must". Once again, consider following possibilities: 1. Library has pure functional interface 2. Library has some data exports, but client never imports them. 3. Library has some data exports, and client does import them. Only the third case requires modification of headers. And IMHO, first two cases account for 80% of time. AO> Not if it can't tell what is the preferrable directory. And, in AO> general, it can't. I'd rather not do a partial job. As for latter clause, I've got idea about that ;-) The same I heard from Garry. I really cannot parse this binary preference - either all or nothing. I'd rather have job done to the extent possible, so I can continue where it stopped and not from the scratch. Far less I'd like dumb computer program's trying to save me from my hell on the basis that something "wr
Re: Ensuring compatibility between libtool components
Hello Alexandre, Alexandre Oliva <[EMAIL PROTECTED]> wrote: AO> I've just thought of a way to avoid any compatibility problems between AO> libtool components: embedding ltconfig, ltmain.sh and ltcf-*.sh in AO> libtool.m4. AC_PROG_LIBTOOL would extract ltconfig and ltmain.sh into AO> the build dir, then proceed to the usual configuration stuff. AO> There are two approaches to extracting the scripts: we may get their AO> contents into the configure script, through some macro, or try to AO> arrange for configure to find them in libtool.m4 or aclocal.m4, AO> avoiding the duplication of the scripts, but risking not finding the AO> m4 file. AO> Opinions? Don't you think it will make maintainance harder, and almost impossible for outsider to find problems when they occur? AO> -- AO> Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[4]: Some DLL-related changes
Hello Gary, Gary V. Vaughan <[EMAIL PROTECTED]> wrote: GVV> [[Moved back to libtool list, but left all the context for people who GVV> don't follow libtool-patches]] GVV> Hi Paul, GVV> Sorry this isn't a full reply -- I'll try to get back to you when I GVV> have had time to look over your patch. Thanks, though it seems that main point - portability problems, expressed here. >> > I still hope to implement way which will allow building dlls without >> > any changes to sources/build files. >> >> Good luck :-) GVV> Been there! I am open to suggestions having hit a few brick walls GVV> myself! I postponed that original work for later time since so far little changes to libtool I posted even before. For example, I built couple of gnome libs without any (dll-related) changes. But just one more deeper step resurrects mutual dependency problem. For example, glib cannot be built properly, since there's cycle between it and gthread. GVV> I need to trawl through my mail archive to jog my memory, but I do GVV> recall being moderately convinced at the time =)O| Then I hope you'll consider my previous patch (libtool-patch from 2000-07-27). >> > It is asked to install (shared) library and should do it. If there's >> > platform on which shared libraries smeared across two files, one >> > called 'implib' and one called 'dll', both preferrably installed in >> > different dirs, it should do it, silently >> >> Not if it can't tell what is the preferrable directory. And, in >> general, it can't. I'd rather not do a partial job. GVV> But with libtool, the dll is *not* smeared across two files. And that's bad. They have to, if we going to solve mutual dep problem. GVV> I wrote GVV> the impgen program so that a static implib is generated on the fly, GVV> allowing libtool to treat the dll part as the whole library for the GVV> rest of the time. *This* is oversimplification. Last anecdote is that cygwin people were so brave to make (some late snapshot of) ld do that automagically. Moreover, they did linking agianst DLL the default (i.e. when asked to link -lfoo and there's (lib)foo.dll and libfoo.a files available in search path (dunno which one), former is selected, in-memory implib created, and app linked against it). However, they fall back (to .a - default) when it became obvious that it gives too much confusion and unexpected results. GVV> The tradeoff is that we have to jump through some GVV> hoops (building and running the impgen program for on the build host) GVV> in order to perform a simple link. The key is in realising that GVV> Windows uses the binary search PATH to find dlls (I know that is an GVV> oversimplification!). [] GVV> Not to mention that ltconfig will go away soon. The only interfaces GVV> to libtool will be via configure.in (and ultimately configure) and the GVV> libtool script itself (presumably as called by the Makefile). All I can say is that it gives me a shiver ;-) GVV> I think that Windows forces us to admit that $shlibpath_var is PATH, GVV> and that a Windows user of libtool generated dlls must have the GVV> library installation directories in their PATH. Maybe we should GVV> install a wrapper script that takes care of this? But isn't it done that way? Wrapper script to run not yet installed binaries sets PATH to required .libs directories. Original talk was however about question where to *install* DLLs. Obvious solution is to the same place where .a files, but that will require additional entry to PATH. Being efficiency liker (hm), I prefer other approach - employ more or less smart heuristics to find $bindir within libtool's runtime scope. >> Thanks for trying to fix this mess. I really hope some day we won't >> have to make contortions to be able to support shared libraries on >> MS-Windows. I wish you luck with the PW effort, even if your aim is >> not to fully replace the way DLLs are built with something that is >> more developer-friendly. GVV> Most definitely! GVV> Cheers, GVV> Gary. -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[2]: DLL naming conventions
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? 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: "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*) 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! 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. CSW> --Chuck -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[4]: DLL naming conventions
Hello Alexandre, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> Yes. And know why? Because they want to support outdated betas! AO> Come on. I've already posted a message saying that we should probably AO> give up on supporting early betas, as long as we detect them as such AO> and disable the creation of shared libraries. It's just a matter of AO> someone implementing it and checking it in. Where's the patch? :-) Well, it took me some time to find out that 1.3.5 is rather dated thingy - I thought it's just two step behind head, but it doesn't even support ILD. Now I reapply my changes to latest head snapshot. Also, I want to build with it the Glib, as a proof of concept. AO> -- AO> Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[4]: DLL naming conventions
Hello Gary, Gary V. Vaughan <[EMAIL PROTECTED]> wrote: Sorry, just when I thought I have some free time, that boss contrived rush. I answer on important points. >> (Technical >> note: what corresponds to shared library on *nix system is a pair of >> on win32. *Pair*) GVV> You're right. I remember why I did it this way now -- the libtool GVV> machinery is not at all equipped to deal with a shared library that is GVV> not in a single file. It is a fair amount of work to teach it to GVV> understand that. I do agree that libtool could be nicer to the world GVV> by installing an appropriate implib. Well, not everything's so bad. Libtool already supports several aliases for shared lib in library_names_spec. Also, there's a convention that last item of it used as the name for linking. This automatically account for linking with implib. There's problem, however, that tail (all but last) names in library_names_spec are treated as symlinks to head. Then, there should be option to not do that. That option consequently changes behaviour of modes: link: do not do anything to tail names at all (assume that files identified by those names produced automagically by external to libtool force) install: instead of linking tail names, copy them. That's what I have done and working. In fact, it's just several lines of changes. I just want to be sure that it works along with all the other changes I did before submitting patch. GVV> Cheers, GVV> Gary. -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[2]: DLL naming conventions
Hello Charles, Charles S. Wilson <[EMAIL PROTECTED]> wrote: [ Talk about versioning on win32 skipped - I'd rather have DLLs being built first, and them go for elaborating their versioning. But I agree with Gary's following letter that mere libfoo.dll.a should suffice - if one would like to have several versions of implibs, one free to do it on his own] CSW> Developing an ld.so runtime loader requires far fewer changes to CSW> libtool, and since you *can* link directly to dll's (*) it'll work 'just CSW> like unix (tm). But developing ld.so will be a tough job. Well, can't stand itch to comment on this. I don't think that porting ELF loader to windows would be very hard. Of course, Linux's ld.so is a mess (well, I even don't know how much ELF handling on Linux is done in ld.so and how much in kernel), but that's not the only source. Just to remember, lxrun could be one. In fact, I even saw someone working ELF .o loader for win32 (of course, it doesn't have loader for shared libs). But what the point would be of such thing? Before I go for it, let me summary some PE-DLL idiosycrasies and how they are accounted by some people vs me: Implibs: I consider implib unalienable part of DLL model, and eager to support this MS feature; I'd never give up it. But DJ Delorie did hack for ld to link against bare dll and Gary put it into libtool. Mandatory data imports marking: I *hate* this feature and develop libtool re-implementation which frees programmer from it. But when I mentioned it on cygwin maillist, DJ Delorie was rather sceptical about it, saying they will support MS way. So, it seems that mileage is really varies unpredictably. My one concerning ld.so on win32 is as follows: it would be just to far-fetched; win32 is about PE, and PE is about DLL, maintaining compatibility and direct interopertability with native way is important to me. YMMV CSW> --Chuck -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[2]: DLL naming conventions
Hello Alexandre, Alexandre Oliva <[EMAIL PROTECTED]> wrote: AO> On Sep 3, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote: >> * When installing a libtool (.la) library: >> - libfoo.la goes to $prefix/lib >> - libfoo.dll goes to $prefix/bin I'm glad this is acknowledged. >> - libfoo.dll.a goes to $prefix/lib >> - libfoo.a goes to $prefix/lib AO> Nope. libfoo.la goes wherever -rpath specified when the library was AO> created; it should be the same directory that is specified at install AO> time. This is often $(libdir), but it doesn't have to be. AO> I don't know how to arrange for an additional directory (bindir) to AO> be specifiable without introducing an additional command-line option. AO> Remember, libtool doesn't know about prefix, libdir or bindir, it just AO> knows about what it's given in the command line. You how I did it ;-) With my python re-implementation, I generate following makefile in .libs and make it: include ../Makefile all: $(INSTALL) $bindir/ So, it uses whatever bindir defined in main makefile. If you remember, I thought that general solution would be something like that, but accounting for MAKEFLAGS in environment (because any of prefix/execprefix/bindir may be overriden on command line), with appropriate fallback if those heuristics doesn't work. But now, I think that's just too messed, It would be easier to add --bindir= option to libtool --mode=install and teach automake supply it. AO> -- AO> Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[4]: DLL naming conventions
Hello Bernard, Bernard Dautrevaux <[EMAIL PROTECTED]> wrote: >> Before I go for it, let me summary some PE-DLL idiosycrasies and >> how they are accounted by some people vs me: >> >> Implibs: I consider implib unalienable part of DLL model, and eager to >> support this MS feature; I'd never give up it. But DJ Delorie did hack >> for ld to link against bare dll and Gary put it into libtool. BD> LD feature is interesting, for DLLs you don't have the implib for and from BD> which you only want to call some simple functions; anything more complicated BD> needs at least header files so you'd probably get implibs also. Yes, it's interesting, but there was way to do that quite simply even without it. So, for me it's superfluous. What is more important, it's not quite easy to do that - there're many things to keep in mind and consider. If it was made once, and then thru the tears and sweat elaborated, it might be not so wise re-surrect all those problems again. That's I guess my very root of reluctance about implibs-on-the-fly. >> >> Mandatory data imports marking: I *hate* this feature and develop >> libtool re-implementation which frees programmer from it. But when I >> mentioned it on cygwin maillist, DJ Delorie was rather sceptical about >> it, saying they will support MS way. BD> I would like to know how you can achieve that ; it would be a *huge* BD> amelioration but I don't have any idea of how to do that, short to recompile BD> everything when linking :-) Just exactly that! And why do you think it is not lively? Specifically, my current implementation does re-assembling on linking - that's to allow for automatical deducing of imported symbols, and defers linking whenever possible (until linking of depending executable or installing) - that's to allow for mutual dependncies. Yes, it needs to store lots of asm (but it can be gzipped ;-) ), but it works blazingly fast comapring to official libtool (it is written in Python). BD> Cheers, BD> Bernard -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[4]: DLL naming conventions
Hello Alexandre, Alexandre Oliva <[EMAIL PROTECTED]> wrote: AO> On Sep 4, 2000, Paul Sokolovsky <[EMAIL PROTECTED]> wrote: >> But now, I think that's just too messed, It would be easier to add >> --bindir= option to libtool --mode=install and teach automake supply >> it. AO> Yep, this is probably the most reasonable solution. But there are AO> still problems. Think of a multilibbed shared library, for example. AO> Since all multilib DLLs would have the same name, only the last one to AO> be installed would remain. To be fair, I don't know what multilib is. But if their installation can be handled on *nix, it also can be handled on win32. For example, if multilibs are didtingushable on automake level, it may *not* pass --bindir while installing them. In such case, libtool will fallback to some default, either the same dir as for .la or ../bin ;-) AO> -- AO> Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[2]: DLL naming conventions
Hello Chris, Chris Faylor <[EMAIL PROTECTED]> wrote: CF> On Mon, Sep 04, 2000 at 09:34:12PM +0300, Paul Sokolovsky wrote: >>Mandatory data imports marking: I *hate* this feature and develop >>libtool re-implementation which frees programmer from it. But when I >>mentioned it on cygwin maillist, DJ Delorie was rather sceptical about >>it, saying they will support MS way. CF> Do you have a URL for this skepticism? I hate marking data imports CF> also. It would be interesting to see what DJ's reasons are. I've CF> never known him to be resistant to good ideas. Well, he wasn't resistant, he was somewhat sceptic. He already explained why - it hardly can be easily and seamlessly working from the first time. But neither I pledge for it. I do it because I need it, and hope to release it because someone may find it useful. That someone hardly will be green newbie but probably programmer who perfectly knows how to build dlls and looking for way to automate it and make more seamless. He probably improve it be more easy to use, etc., etc. and that way one day even greener will be able to use (or maybe it will be used by default? ;-) ) http://www.delorie.com/archives/browse.cgi?p=cygwin/2000/05/03/10:32:40 Btw, that whole thread was started about enumerating bugs in then-current binutils, 19990818. But from DJ's letter I'm afraid they are all there, and even those I thought dead forever are re-born. I currently don't have access to box where I have cygwin, and have resources to re-download it, so if someone have interest, please re-check them. CF> Anyway, it would be interesting to see how you work around this. I CF> can't think of any way to handle this without changing the compiler and CF> the linker. Nor I claim that it might be. But since I'm not gcc hacker, and ld hacking is too expensive for mere experimenting, I prefer detached techniques. Sketching my idea (I did it in thread above, IIRC), there are several steps which source undergoes before became executable: 1. First, there's source 2. Then, it is preprocessed 3. Then, it is compiled into assembler 4. Then, it is assembled into object 5. Then, objects linked into executable Standard MS way is to have imported symbols marked so on stage 1, and to do that manually. So, first idea was to automate it. Result is my a2dll (http://www.is.lg.ua/ftp/gnuwin32/altbinutils/a2dll-1.0.zip) script which works following way: 1. You build static library 2. Then, you run a2dll upon static lib 3. If you're lucky, you get dll and implib (as drop-in replacement for static lib) and quest is over 4. If you're not lucky, you get dll, implib, and list of data symbols, exported by that dll 5. You run grep -F *.h to get an idea where those data are declared (well, in next version I will run it automatically). 6. Paste appropriate macro in front of each declaration. Not so bad, I think. Of course, I thought about automating point 6 above too. As I told, hacking gcc would be hard for me, so one evening I took some make-prototypes type utility with aim to make it output something like: : Unfortunately, I chose wrong one - that even wasn't able to parse full C declaration. When, at 2a.m., I finally got it working I figured out that it fails with very it's own header because it outputs location as of preprocessed file... So, I just removed it all and went to sleep. Now I think it could be possible to carry on, but on level 2 as of picture above. Well, anyway, I imagined all those 5-stage procedure clearly and questioned very requirement to do it on source level. It's obvious that imported symbols can be inferred autmatically, and precisely on the level 4. But of course, it won't be easy to act upon such information in machine code. So I've choose assembly level, and since info on imports not immediately available, it's all about deferred compilation and linking. The rest is purely implementation technique. CF> cgf -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[2]: libtool
Hello Charles, Charles S. Wilson <[EMAIL PROTECTED]> wrote: CSW> I don't believe the following behavior is possible in the current CSW> libtool. However, if it is, please correct me. CSW> In the upcoming libtool (1.4?) it would be nice on cygwin/windows-ish CSW> platforms, if the libfoo.la file could instruct libtool that it may need CSW> different -Ddefines when compiling an object file that is to be linked CSW> to a static lib or to a dynamic lib (dll). CSW> gcc -c -DZLIB_STATIC -o my-file.o myfile.c CSW> gcc -static -o my-file.exe my-file.o -L -lz CSW> gcc -c -o my-file.o myfile.c CSW> gcc -o my-file.exe my-file.o -L -lz This behaviour impossible simply because libtool is not used for compiling client objects, only when compiling library objects, and linking - both clients and libs. As you understand, it's probably far-fetched to expect that libtool interface will be changed because there's such a platform with such a stupid requirement. It is however, can be trivially and more or less seamlessly worked around *on that specific platform*, I use CC="libtool gcc" for that. But that workaround is only one in a long sequence of workarounds which will be required to support something more or less similar to features libtool offers on any other platform, workarounds which will be required if keeping up with stipulations prescribed by microsoft. But it's better to strike the root of problems - get rid of necessity for __declspec. CSW> --Chuck -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135
Re[2]: Support pw32 as gnu-win32 target
Hello Gary,
Gary V. Vaughan <[EMAIL PROTECTED]> wrote:
GVV> On Sun, Sep 10, 2000 at 12:57:46PM +0300, Paul Sokolovsky wrote:
>> Hello libtool-patches,
GVV> Hello =)O|
>> Here's first chunk of my patches - since some are probably will
>> require corrections, I decided to split them starting with most
>> harmless.
GVV> Thanks, that is much appreciated. However you attachments have been
GVV> truncated, or else you generated the patch with the wrong version.
GVV> Almost all of what you mention in the Changelog entry is missing =(O|
Strange, I did diff against CVS head, copy of message returned to
me contains everything I put there. Unfortunately, there's no online
archive of libtool-patches (why?), so I can't look there.
>> There are support for pw32,
GVV> I can see some of this, but it was incomplete. I have applied
GVV> something similar, under the assumption that pw32 takes '/' delimited
GVV> paths, and has no libc or libm (-lc and -lm are discarded). It is no
GVV> coincidence that this is the same mode of operation of libtool under
GVV> cygwin =)O|
Thanks! That's what I wanted first of all - shorten size of my
patches.
>> giving up using hyphens as revision numbers delimiters,
GVV> DJGPP (and presumably other DOS ports of gcc) uses 8.3 filenames, so
GVV> only a single `.' is allowed. I accept that the current
GVV> libfoo-p-q-r.dll already violates the 8.3 limit, but I would like to
GVV> support DJGPP better than we do already. I guess this means I need to
GVV> install it, and see what breaks. Awaiting your patch =)O|
GVV> Agreed in principle, however we need to be careful of 8.3 again =(O| I
GVV> guess this means special casing DJGPP.
But how that influence DJGPP or other DOS ports of gcc? That
change applies only to win32 hosts (in fact, only to gnu-win32, I
intentionally left hyphen-delimited naming for non-gcc's). Only time
this may apply is when cross-compiling from djgpp to gun-win32 host.
Well, then:
- If it is done on one of win9x systems, LFN facility is used which
transparently proxies win32 naming to djgpp apps.
- For NT systems, there're separate package to achieve that.
- Only when one does that on bare dos, that will be problem. But I
guess it's fair to suggest in such case to take care that djgpp
convert filenames to representation acceptable by underlying layer.
(And IMHO, this might be done in official djgpp - well, maybe it's
even done already, I'm looking at 2.01 _put_path()).
>> Note comented line with s/^lib/cyg/ - that's about my proposal for
>> using cyg prefix for cygwin dlls.
GVV> I would like a patch that allows an extra libtool option to name the
GVV> dll part of a win32 shared library as specified by the developer. I
GVV> think the cleanest way to do this is to add a `-soname FILENAME'
GVV> option to the link mode of ltmain.in, which on win32 is use to name
GVV> the dll part, but is passed to the linker by default. Maybe we need
GVV> to intercept -Xlinker,-soname and -Wl,-soname too? Alexandre, do you
GVV> have any suggestions on how to go about this?
GVV> Anyway, such a system will allow sensible cygwin developers to use
GVV> libtool --mode=link gcc -no-undefined -soname cygfoo.dll
GVV> And you to use
GVV> libtool --mode=link gcc -no-undefined -soname pwfoo.dll
GVV> from the same codebase.
But my original patch (hm, below) would allow to save sensibility
for something more useful. Don't provide excess configurability when
it's hardly needed. (Automake won't generate that option specially for
gnu-win32, will it? And when I would like DLL name to differ from
standard, I can simply rename it after building.) YMMV
if test "$ac_cv_prog_gcc" = yes; then
-library_names_spec='${libname}`echo ${release} | sed -e
's/[.]/-/g'`${versuffix}.dll'
+case "$host_os" in
+# cygwin*) library_names_spec=`echo ${libname} | sed -e
+'s/^lib/cyg/'`'${release}${versuffix}.so $libname.dll.a' ;;
+ pw32*) library_names_spec='${libname}${release}${versuffix}.so
+$libname.dll.a' ;;
+ *) library_names_spec='${libname}${release}${versuffix}.dll
+$libname.dll.a' ;;
+esac
else
library_names_spec='${libname}`echo ${release} | sed -e
's/[.]/-/g'`${versuffix}.dll $libname.lib'
fi
GVV> Cheers,
GVV> Gary.
--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135
Re: [Libtool] Re: Naming a project gnu-win32?
Hello Richard, [Sorry for crossposting to libtool list, but I don't risk cc this to cygwin list] Richard Stallman <[EMAIL PROTECTED]> wrote: Chris Faylor <[EMAIL PROTECTED]> wrote: CF> An issue has recently been raised (by me) in the libtool mailing list CF> regarding the desirability of using the label "gnu-win32" in scripts CF> like libtool (and, I presume, configure). Original note was talking about making technical feature which applies to all targets using GNU compiler/linker/other utilities to produce applications for set of systems (aka platform) officially called 'Win32', and not about putting anything containing substring 'gnu-win32' into libtool or configure. And that was colloquial note, not official statement for press. Of course, there can be made agreement upon euphemism like 'cygwin and its shameless, ingrate offshots' or 'gnu-w', but who will serve as a censor (maybe add a note to GNU Coding Standards? ;-) ). Apart from that, there're lots of outsiders - using cryptic names hardly will help them to get interested with the stuff. And yes, I believe that promotion of 'GNU compiler/linker/other utilities for producing applications for set of systems (aka platform) officially called 'Win32'' (hereafter referred as 'gnu-win32') will help both GNU Project and Free Software as a whole - I don't believe your original reasoning example for 'gnu-win32' is sound - for me, it means "there is thing called win32 (and you know what it is, don't you?), but even it hasn't been allowed to live benighted - it was civilized by GNU". RS> In hacker terminology, calling something a "win" is a form of praise. RS> People who wish to praise Microsoft Windows are free to do so, but in RS> the GNU Project we don't do it. So we write either "Windows" or "w", RS> not "win". But what to do the people who just want to refer to system with official name "Win32"? I don't remember unix-haters teasing about "how such a mishmash, unbeautiful OS could be named such", so why peak about some vendor's choosing letters for name of their system? I guess even Microsoft's advertising managers could hardly imagine that that name would make GNU Project sway supporting that os, and thus preserving their monopoly across large share of market. Let them name it whatever they want - for example, their last craft named 'Windows Me' (Who Windows Me? Don't Window Me!) CF> Anyway, there is now a new, unrelated project now that is billing itself CF> as "gnu-win32" and I thought it might be a good idea to alert you to CF> this before the name started popping up in configure and libtool CF> scripts. That name is short and precise reference to the bunch of targets sharing many common properties. But there's no such target, such an option or even a variable name. If you pledge for not inclusion that even in comments, make final decision for substitute. RS> If these people want to be part of the GNU Project, they ought to talk RS> with me about this project in any case. Could you send me some brief RS> info about the project, and the email addresses of the leaders (only), RS> so I can talk with them? I could try to give some info for that (subject for disagreement with what Chris Faylor may say). Apart from Cygwin, the official part of GNU Project, there're some others too. They all use GNU core development packages (gcc/binutils), and utilise PE-COFF support initially done for Cygwin. In fact, all they are differ is runtime libraries, their completeness and licenses. The oldest (from 1998) is called 'Mingw', homepage http://www.mingw.org, current maintainers can be reached at [EMAIL PROTECTED] . It cannot be part of official GNU Project because most important part of it is in public domain, and it is maintainers' attitudes to keep it so (and it's understood - clean-roomedness of implementation of win32 headers can be challenged, and it is authors' playing safe to disclain any interest in them apart from doing 'public good'). But there still some problem can be found with Mingw - technically speaking, Mingw is acronym for 'Minimalist GNU Win32'. Here, again, GNU doesn't refer to being official part of a project, but to basing on GNU toolset. Since that string is just informal description, and not a name, I hope you won't request to hide it away. There's also other, 'PW32', hack of mine (http://pw32.sourceforge.net). It hardly can be compared by user base with Cygwin or Mingw. I don't have ambitions for it to become part of GNU either; even if I would, it couldn't be done since I'm basing on DJGPP's libc, copyright of which is held by DJ Delorie. -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ld --auto-imports
Hello Robert, âîñêðåñåíüå, 10 èþíÿ 2001 ã., you wrote to me: RC> Hi Paul, RC> You may not recognise my name - I hack on the cygwin1.dll internals RC> among other things. Ralf Habacker put me onto your auto-imports RC> patch/hack for ld 2.11. I hope you don't mind me writing you direct, I RC> wasn't sure hwat list was appropriate. Feel free to redirect me, or copy RC> any reply to a list of your choice. I guess binutils list is a place to discuss this, and it fact I'd appreciate such mails appearing there - likely, it won't be too easy to get that patch included, so it would be nice if messages showing that community reviews patch were sent there. I'm not subscribed to it, however, so I'd appreciate cc: to me. RC> Your ld patch looks very nice, and I have a modified libtool-HEAD here RC> that using it rather than a 5 stage dllwrap process. You may want to know that I did it quite some time ago, along with other useful changes. It is available at http://sourceforge.net/projects/pw32/ . It worked OOB for me for stuff I tried it on (glib/gtk+ libs, for example). Ralf Habacker reported it worked ok for him with cygwin (even though package on the link above built for my PW32). RC> I've a small bit of feedback/a question, and a more serious question. RC> Firstly the feedback. I'm using a pre-compiled version from Ralf RC> habacker. That version (and AFAIK it's a stock build) creates the .dll RC> base image at 0x610c which collides with the cygwin1.dll. Now the RC> cygwin1.dll is theoretically relocatable, but we've just found out that RC> it doesn't like relocating :/. According to MSDN, the default image base RC> for .dll's should be 0x1000. Is there any reason your modified ld RC> couldn't set that as the default base address for .dlls? That would RC> remove the need to add --base-address=0x1000 to the link line in RC> libtool. Well: 1. As you understand, it is not connected with auto-import stuff in any way. That's how Ralf Habacker built it. 2. Having specific base hardcoded is bad anyway - you'll get collisions (automatically resolved, of course). Far better to --enable-auto-image-base switch to ld and let it choose unique base itself (based on hashing of dll name, etc.) 3. With my personal attitudes, ld on win32 should work as close to normal unix version as possible. Mundane unix system doesn't have any idiosynacrasies around "relocatability" - so, --enable-auto-image-base should be the default as it offers most seamless solution to win32 strangeness. The same for --enable-auto-import . That's how I tried to do while maintaining binutild fow Mingw32. Well, new maintainer doesn't share these ideas, so having that all in libtool is not worst solution ;-) RC> Now for the more serious question. Does your patch in theory support RC> dll's linking to other .dll's with auto-imports? Of course, why not? I wouldn't claim I tested that, however. RC> I have a trivial hello RC> world case here (built with my libtool, but I'm very sure the symptoms RC> will be the same without libtool) that segfaults _every time_. That RC> testcase has 3 source files, 2 libraries. RC> hello.exe - depends on cyghello-0.dll RC> cyghello-0.dll - depends on cyggreet-0.dll RC> cyghello-0.dll reads a string from cyggreet-0.dll, and writes it + , RC> World! to stdout. RC> Thanks for any suggestions you can offer. I'm happy to drop you the RC> trivial testcase, and/or prepare a non-libtool testcase that shows the RC> same symptoms - if that would help. Please provide one. I'd appeciate if it were not just mere gcc/ld based, but also wouldn't depend on cygwin (i.e. were built with -mno-cygwin or standalone mingw). RC> Rob -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: About win32 impgen.c patch (fwd)
Bob Friesenhahn wrote: [] Comments? Should pw32 be tracking Cygwin and MinGW in libtool rather than being left behind? Yes, please, if it's not hard, pw32 can follow the same sequence as mingw. As for general point of removing (parts of) impgen.c, I cannot give adequate answer as I don't have sources handy. IIRC, it belongs to ld. And it's nice to have ability to create all the DLL stuff (even adhoc bits like implib) with mere ld (== it's easier for non-win32-savvy people to port the stuff). On the other point, there's duplication of functionality with dlltool... Due to advances in binutils, both Cygwin and MinGW no longer use impgen, or even dlltool, from libtool. I assume it that pw32 benefits from the same gcc/binutils enhancements. Nice to hear, that's what I always dreamed of. My point is that even if they are not used most of the time, they probably could still stay with binutils, as a possible means to extend support to win ce/non-ix86/etc. Do you recommend that all libtool cases which look like cygwin* | mingw* ) be extended to cygwin* | mingw* | pw32*) and the cruft currently attributed to pw32 (using impgen and dlltool) be removed? Yes, exactly. If there're different paths for cygwin and mingw somewhere, pw32 can follow mingw. There is no one currently supporting the pw32 support in libtool, and until yesterday, none of the currently active maintainers even knew what pw32 was. This means that pw32 support in libtool has fallen into disrepair. Well, I know that pw32 is in some use (even though I do not do active development of it now). If it won't take much of effort from maintainers, I'd appeciate the changes discussed. Bob ====== Bob Friesenhahn Thanks, -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
