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>

Very reason for not using gcc to link shared libraries?

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?

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 Oliva

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 >>

Re[4]: State of win32 dll support in libtool at CVS

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

Proposal: globalizing 'libtool' creation method

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 s

Re[2]: Status of availability of features which allow correct and seamless support of DLLs in current GNU-Win32 releases

T>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 <[EM

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\l

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 sur

Re: Ensuring compatibility between libtool components

gt; 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

Re[4]: Some DLL-related changes

ndir 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

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 t

Re[4]: DLL naming conventions

t 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

l 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

ws: 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

, 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

matical 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 i

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

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 >>ment

Re[2]: libtool

ong 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 n

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 correction

Re: [Libtool] Re: Naming a project 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'

Re: ld --auto-imports

27;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 wit

Re: About win32 impgen.c patch (fwd)

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 Fr