Re: libtool and cl
On Fri, 28 Mar 2003, Robert Boehne wrote: Braden, For libltdl to work, you'd have to have Windows declspec(__dllimport) and declspec(__dllexport) applied properly, which isn't currently done. As far as libname.lib It used to be supported by libltdl, but when GCC implemented the auto-import capability, Gary removed the support. I think it was a bad idea to remove the support. There are plenty of reasons to use the Microsoft compiler rather than GCC under Windows since GCC has limited functionality under Windows. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and cl
On Fri, 2003-03-28 at 23:04, Robert Boehne wrote: Braden, For libltdl to work, you'd have to have Windows declspec(__dllimport) and declspec(__dllexport) applied properly, which isn't currently done. As far as libname.lib being used for both static dynamic, AIX uses libname.a for both, and in fact, libname.a can be BOTH a static dynamic library in the same file under AIX. What we do for AIX is we only build one or the other, i.e. if --enable-shared is passed, we build shared only. I don't think it would take much work to get this up and running. That approach works for me; I'll pursue it. Thanks... -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and cl
On Sat, 2003-03-29 at 10:19, Bob Friesenhahn wrote: On Fri, 28 Mar 2003, Robert Boehne wrote: Braden, For libltdl to work, you'd have to have Windows declspec(__dllimport) and declspec(__dllexport) applied properly, which isn't currently done. As far as libname.lib It used to be supported by libltdl, but when GCC implemented the auto-import capability, Gary removed the support. I think it was a bad idea to remove the support. There are plenty of reasons to use the Microsoft compiler rather than GCC under Windows since GCC has limited functionality under Windows. Any chance you recall the last release to include that support? -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and cl
Bob Friesenhahn wrote: On Fri, 28 Mar 2003, Robert Boehne wrote: Braden, For libltdl to work, you'd have to have Windows declspec(__dllimport) and declspec(__dllexport) applied properly, which isn't currently done. As far as libname.lib It used to be supported by libltdl, but when GCC implemented the auto-import capability, Gary removed the support. I think it was a bad idea to remove the support. There are plenty of reasons to use the Microsoft compiler rather than GCC under Windows since GCC has limited functionality under Windows. Limited how? Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and cl
On Sat, 29 Mar 2003, Max Bowsher wrote: It used to be supported by libltdl, but when GCC implemented the auto-import capability, Gary removed the support. I think it was a bad idea to remove the support. There are plenty of reasons to use the Microsoft compiler rather than GCC under Windows since GCC has limited functionality under Windows. Limited how? GCC does not support most of Microsoft's non-standard C C++ extensions. GCC also is not C++ ABI compatable with Visual C++. This means that GCC can't be used to compile programs based on ATL or MFC, which many Windows programers prefer to use over the base C APIs. I suspect that GCC does not yet support compiling for Microsoft's .net environment. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and cl
Braden McDaniel wrote: It used to be supported by libltdl, but when GCC implemented the auto-import capability, Gary removed the support. I think it was a bad idea to remove the support. There are plenty of reasons to use the Microsoft compiler rather than GCC under Windows since GCC has limited functionality under Windows. Any chance you recall the last release to include that support? 1.4.3 g Seriously, try CVS prior to May 31, 2001. That's when the first of the auto-import stuff went into CVS AFAIK. But, for the love of pete, PLEASE do not re-add that cruft willy-nilly. Keep it nicely segregated from mingw, cygwin, and pw support; I don't want to see ANY of that creep back into the cygwin execution path. This will require significant refactoring of the code -- especially since May 31, 2001 was ALSO prior to the multi-tag changes. Which means that the old support knows nothing about multiple tags, in addition to its commingled status wrt cygwin/mingw/gcc. Resurrecting that code will be a large chunk of work. Unfortunately, I don't have the time to rebuild on cygwin after every commit to make sure stuff didn't get broken. PLEASE be careful not to disturb the other windows-based compilers. This talk of mucking around with libtool on my platform (e.g. windows; cl/mingw/cygwin/pw are all somewhat related in the underlying OS) this close to 1.5's release gives me the screaming heebie-jeebies. I've waited over two years for a decent libtool -release- on cygwin that *really* supports building shared libs transparently and in the unix way...it works now, and I'd be terribly pissed to see it broken at T-3weeks. With respect to Bob, Gary's decision to remove it was correct at the time. Unmaintained, untested code should NOT simply be carried along because it might be needed later. It would have made development on actual used and tested platforms [e.g. cygwin/mingw] for the past 21 months much harder, for very little benefit. The old code will always be there -- in CVS archives -- if anybody wants to up-port it. But no one did, and no one was available, and apparently no one needed it until now. That's 21 months of pain, avoided. I'm cool with that. Also wrt Bob, concerning mingw vs cl: IMO, if you're using cl and relying on its non-standard extensions to C and C++, then you are obviously not trying to write portable code. In that case, you should simply use the MSVC support for building DLLs and static libs, and NOT use libtool or autoconf or automake at all. Since you're not worried about portability, use the tools MS provides to make your life easier; why go thru the pain of creating a *build* system that is portable, when your *code* is not? The autotools are about portability. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and cl
On Sat, 2003-03-29 at 18:05, Charles Wilson wrote: Braden McDaniel wrote: It used to be supported by libltdl, but when GCC implemented the auto-import capability, Gary removed the support. I think it was a bad idea to remove the support. There are plenty of reasons to use the Microsoft compiler rather than GCC under Windows since GCC has limited functionality under Windows. Any chance you recall the last release to include that support? 1.4.3 g Seriously, try CVS prior to May 31, 2001. That's when the first of the auto-import stuff went into CVS AFAIK. But, for the love of pete, PLEASE do not re-add that cruft willy-nilly. Keep it nicely segregated from mingw, cygwin, and pw support; I don't want to see ANY of that creep back into the cygwin execution path. This will require significant refactoring of the code -- especially since May 31, 2001 was ALSO prior to the multi-tag changes. Which means that the old support knows nothing about multiple tags, in addition to its commingled status wrt cygwin/mingw/gcc. Resurrecting that code will be a large chunk of work. Thanks for the info. Unfortunately, I don't have the time to rebuild on cygwin after every commit to make sure stuff didn't get broken. PLEASE be careful not to disturb the other windows-based compilers. This talk of mucking around with libtool on my platform (e.g. windows; cl/mingw/cygwin/pw are all somewhat related in the underlying OS) this close to 1.5's release gives me the screaming heebie-jeebies. I've waited over two years for a decent libtool -release- on cygwin that *really* supports building shared libs transparently and in the unix way...it works now, and I'd be terribly pissed to see it broken at T-3weeks. Unless 1.5 is a lot farther off than I hope it is, I have no expectation that such changes could go in prior to that release. With respect to Bob, Gary's decision to remove it was correct at the time. Unmaintained, untested code should NOT simply be carried along because it might be needed later. It would have made development on actual used and tested platforms [e.g. cygwin/mingw] for the past 21 months much harder, for very little benefit. The old code will always be there -- in CVS archives -- if anybody wants to up-port it. But no one did, and no one was available, and apparently no one needed it until now. That's 21 months of pain, avoided. I'm cool with that. Also wrt Bob, concerning mingw vs cl: IMO, if you're using cl and relying on its non-standard extensions to C and C++, then you are obviously not trying to write portable code. In that case, you should simply use the MSVC support for building DLLs and static libs, and NOT use libtool or autoconf or automake at all. Since you're not worried about portability, use the tools MS provides to make your life easier; why go thru the pain of creating a *build* system that is portable, when your *code* is not? The autotools are about portability. Using cl does not imply relying on its non-standard extensions. As it happens, a *lot* of portable code gets compiled with cl. It would be very useful to be able to use the autotools in that situation. -- Braden McDaniel e-mail: [EMAIL PROTECTED] http://endoframe.comJabber: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool