From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mumit Khan To: Emanuele ALIBERTI Cc: cygwin@sourceware.cygnus.com Subject: Re: Dlls @n symbols Date: Thu, 24 Jun 1999 11:23:00 -0000 Message-id: <199906241715.MAA10937@mercury.xraylith.wisc.edu> References: <19990624071517.16896.qmail@hotmail.com> X-SW-Source: 1999-06/msg00586.html Emanuele ALIBERTI writes: > > >It turns out that Suhaib's problem is very different than yours. > > It may be I misunderstood it. Sorry, I should've been clearer. Suhaib and I had been communicating privately, and the problem has to do with incorrect prototyping of __stdcall__ functions, nothing to do with DLLs. > >What you're telling the dll tools is that you want to link with Bar@0, but > >have the DLL export Bar; similarly with Foo. One way to get both in the > >export list is the following: > > > > LIBRARY sample > > EXPORTS > > Bar@0 > > Bar=Bar@0 > > Foo@24 > > Foo=Foo@24 > > > >Now sample.dll exports both Foo and Foo@24. > > The goal for me is: > 1. NOT having mangled names in the exports table > 2. having an import library which lets ld lookup mangled names > 3. having finally an application that imports UNmangled names > > I succeeded only with step 1. I don't understand (2) and (3). Could you please elaborate, with examples, and then we can discuss if they're feasible or not. If these steps are not possible with MSVC or Borland, chances are it won't be easily doable or practical in GNU tools either. One thing that MSVC does, and it's very handy, is the following: EXPORTS foo where foo can be __cdecl__ (ie., just _foo) or __stdcall__ (ie., _foo@) and it'll do the right thing. This is quite impractical to do with dlltool, but perhaps in the new ld that will support --shared directly. > Thank you for answering and the URL. Here's the correct URL. http://www.xraylith.wisc.edu/~khan/gnu-win32/dllhelpers.html Regards, Mumit -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mumit Khan To: Emanuele ALIBERTI Cc: cygwin@sourceware.cygnus.com Subject: Re: Dlls @n symbols Date: Wed, 30 Jun 1999 22:10:00 -0000 Message-ID: <199906241715.MAA10937@mercury.xraylith.wisc.edu> References: <19990624071517.16896.qmail@hotmail.com> X-SW-Source: 1999-06n/msg00586.html Message-ID: <19990630221000.wlGlvViFk3eeRoOcIwLZxEF9Vqc8z2TxgXHsyqweIOg@z> Emanuele ALIBERTI writes: > > >It turns out that Suhaib's problem is very different than yours. > > It may be I misunderstood it. Sorry, I should've been clearer. Suhaib and I had been communicating privately, and the problem has to do with incorrect prototyping of __stdcall__ functions, nothing to do with DLLs. > >What you're telling the dll tools is that you want to link with Bar@0, but > >have the DLL export Bar; similarly with Foo. One way to get both in the > >export list is the following: > > > > LIBRARY sample > > EXPORTS > > Bar@0 > > Bar=Bar@0 > > Foo@24 > > Foo=Foo@24 > > > >Now sample.dll exports both Foo and Foo@24. > > The goal for me is: > 1. NOT having mangled names in the exports table > 2. having an import library which lets ld lookup mangled names > 3. having finally an application that imports UNmangled names > > I succeeded only with step 1. I don't understand (2) and (3). Could you please elaborate, with examples, and then we can discuss if they're feasible or not. If these steps are not possible with MSVC or Borland, chances are it won't be easily doable or practical in GNU tools either. One thing that MSVC does, and it's very handy, is the following: EXPORTS foo where foo can be __cdecl__ (ie., just _foo) or __stdcall__ (ie., _foo@) and it'll do the right thing. This is quite impractical to do with dlltool, but perhaps in the new ld that will support --shared directly. > Thank you for answering and the URL. Here's the correct URL. http://www.xraylith.wisc.edu/~khan/gnu-win32/dllhelpers.html Regards, Mumit -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com