Re: libtool and cl
Charles Wilson wrote: 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. Amen, preach it brother. My sentiments exactly. 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. Well the autotools are to try to make portability easier for the non-portable parts of various environments. I don't see this any different from any of the rest of the support we do based on system specifications. I suggest for good examples for support for cl that you look at what Mo DeJong has done with SourceNavigator. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
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
libtool and cl
Has anyone in earshot here given any thought to what it might take to fix libtool's cl (Microsoft Visual C++ compiler) support? I have an interest in fixing this, and I'm in the process of poking around to see what it's gonna take. I am far from an expert on MS Windows libraries; but I'm prepared to fake it. The stickiest point I've found so far is that libname.lib can refer either to a static library, or an import library that is associated with a DLL. This has two significant ramifications for libtool: * libtool's current assumption that libname.lib when it appears on the command line refers to a static library is not valid. But because there's no syntactic difference in the way import libraries and static libraries are specified to cl, libtool should simply proceed regardless. This doesn't seem hard to address. * When building both static and shared (DLL) libraries, there will be a problem in that the import library created along with the DLL will have the same name as the static library. The static library could be disambiguated, of course; but that raises the question of whether the disambiguation should be applied silently by libtool to try to locate a library prior to linking. For example, if the disambiguation of foo.lib results in libfoo.lib, should libtool convert a reference to foo.lib on the command line to libfoo.lib if foo.lib cannot be found? The latter issue stands to get into munging command line parameters. If libtool Goes There, then perhaps it should just accept POSIX-style -l parameters instead and convert them into things cl understands. Thoughts? -- Braden McDaniel [EMAIL PROTECTED] Software Engineer, Object Sciences Corporation ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
