Re: pr-msvc-support merge
Hi Gary! Den 2010-06-09 16:46 skrev Gary V. Vaughan: Hi Peter, [[Adding libtool list]] On 9 Jun 2010, at 20:21, Peter Rosin wrote: Den 2010-06-09 14:50 skrev Gary V. Vaughan: As far as I can tell, you are eminently more qualified than me to know whether your patches are likely to have issues. If we can't do a straight merge from your branch to master after 2.2.10 is rolled, then I suggest you cherry pick as you see fit to a new merge-branch branched from current master, but ping the list before you pull the trigger if there's anything you want to iron out first. When you have everything in order, I'll test the result on all the hosts I have access to... if I hit any problems, we can iron those out on the list too, and then merge to master when we're done. Then I suggest that we start with the archiver thing, as that is what the first patch on the branch is about (see below). This is all assuming that your changes are deep. If not, and you think it will be easier and/or faster to cherry pick straight into master discussing as we go, I'm happy to do that too, although branching and merging are so easy in git that we'd have to absolutely sure that we're not making master any worse than the previous commit each time we add to it. The first three are probably not that bad, but the last one (8c17887...) needs...further discussion. It was discussed, but it dead-ended as usual [1]. Here's a mid-point message [2] that is good if you get interested and want to find the start of that discussion... (*) fbc144008bd66848111fb8ef2d7293b33957ea1a The way you skip the last reload part of the test makes it look as though the entire test-group has been skipped. I think you should put the reloadable object test inside a separate AT_SETUP/AT_CLEANUP, and skip just that part. Doesn't that mean that all the compiling/linking has to be done twice, once for each AT_SETUP? Is it worth it? Anyway, we'll get to this in due time I suppose. Let's take care of the older patches first... 06cfce005204bb8ca212aadab38b38c0202ea04e This is just documentation? I'd rather the documentation is added (maybe in several stages) along with the code changes that require that documentation. Agreed. 2817364bb6efd20192c46edecfe085cbb288 Looks good. Good to know, but it depends on the other stuff... So, it will have to wait. 8c17887ee34e73a2aeb127b94f5b76f45dc34017 Why so much cruft in ltmain.m4sh just to drive a different archiver? It seems to me that this would be better and easier to maintain, test and extend as a whole new script. Let's call it, $prefix/libexec/libtool/ar, build it from $srcdir/libltdl/config/ar.m4sh, and have libtool set AR to point at the script instead of /usr/bin/ar when the system is funky. WDYT? Sound appealing! I didn't want libtool to mess with $AR, so I introduced another layer of indirection through a new $LTAR variable that libtool can set to the "libtool --mode=ar" fallback for funky archivers. My way requires interaction with automake but that's not needed if there's no problem with libtool messing with $AR. I have a patch somewhere that adds tracing to make all available libtool modes detectable by automake and a 'tiny' automake patch somewhere else that uses that to determine if the extra layer of indirection is available, should I go digging for those patches or is "my way" just too ugly? Hmmm, the extra layer of indirection is orthogonal, isn't it? You should know that this ar wrapper thing is an alternative to commit 0bb52ed03e71109ef75f8d72439ea1365ae14f42 with the core idea to use a new variable $AR_SEP to handle some of the funkiness of the MS archiver. The problem with that is that $AR_SEP needs to be a space in the normal case, and a single space is not easily stored as the variable content in makefiles. Your way is also a bit over the top of my head. I don't know how to create the infrastructure in the build system, so I'm going to need help with that... Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: pr-msvc-support merge
Hi Peter, On 10 Jun 2010, at 14:35, Peter Rosin wrote: > Den 2010-06-09 16:46 skrev Gary V. Vaughan: >> As far as I can tell, you are eminently more qualified than me to know >> whether your patches are likely to have issues. If we can't do a straight >> merge from your branch to master after 2.2.10 is rolled, then I suggest >> you cherry pick as you see fit to a new merge-branch branched from current >> master, but ping the list before you pull the trigger if there's anything >> you want to iron out first. When you have everything in order, I'll test >> the result on all the hosts I have access to... if I hit any problems, we >> can iron those out on the list too, and then merge to master when we're >> done. > > Then I suggest that we start with the archiver thing, as that is what the > first patch on the branch is about (see below). Ack. >>> The first three are probably not that bad, but the last one (8c17887...) >>> needs...further discussion. It was discussed, but it dead-ended as usual >>> [1]. >>> Here's a mid-point message [2] that is good if you get interested and want >>> to find the start of that discussion... >>> >>> (*) fbc144008bd66848111fb8ef2d7293b33957ea1a >> >> The way you skip the last reload part of the test makes it look as though >> the entire test-group has been skipped. I think you should put the >> reloadable >> object test inside a separate AT_SETUP/AT_CLEANUP, and skip just that part. > > Doesn't that mean that all the compiling/linking has to be done twice, once > for each AT_SETUP? Is it worth it? Anyway, we'll get to this in due time I > suppose. Let's take care of the older patches first... Good point. Okay, it's your call. >>>8c17887ee34e73a2aeb127b94f5b76f45dc34017 >> >> Why so much cruft in ltmain.m4sh just to drive a different archiver? It >> seems to me that this would be better and easier to maintain, test and extend >> as a whole new script. Let's call it, $prefix/libexec/libtool/ar, build it >> from $srcdir/libltdl/config/ar.m4sh, and have libtool set AR to point at the >> script instead of /usr/bin/ar when the system is funky. >> >> WDYT? > > Sound appealing! I didn't want libtool to mess with $AR, so I introduced > another layer of indirection through a new $LTAR variable that libtool > can set to the "libtool --mode=ar" fallback for funky archivers. My way > requires interaction with automake but that's not needed if there's no > problem with libtool messing with $AR. Well, I think we'll need a parallel patch for automake anyway, since automake has lib_LIBRARIES which may very well call $AR without involving libtool at all. Which makes me think that once we have our wrapper working, it makes more sense to contribute it to automake than release it with libtool. > I have a patch somewhere that adds tracing to make all available libtool > modes detectable by automake and a 'tiny' automake patch somewhere else > that uses that to determine if the extra layer of indirection is > available, should I go digging for those patches or is "my way" just too > ugly? I dunno. It's not the way I would have done it, but in the end you've done all the work, and you'll likely be the one who keeps it all working in the face of other changes to libtool down the line. So you get to choose whether you'd like to put more work in up front to minimise the amount of maintenance you need later on. Your call entirely :) > Hmmm, the extra layer of indirection is orthogonal, isn't it? I'm not sure exactly what you mean. Certainly we (and eventually Automake) will need to figure out what to put in AR, but while we get it working, I see no harm in unconditionally using: 'AR = $(auxdir)/ar' > You should know that this ar wrapper thing is an alternative to > commit 0bb52ed03e71109ef75f8d72439ea1365ae14f42 > with the core idea to use a new variable $AR_SEP to handle some of the > funkiness of the MS archiver. The problem with that is that $AR_SEP > needs to be a space in the normal case, and a single space is not > easily stored as the variable content in makefiles. I think we get to sidestep that whole issue by having the ar wrapper figure it out at runtime for the best flexibility and reusability of the same script when jumping between cygwin/msys/mingw etc. > Your way is also a bit over the top of my head. I don't know how to > create the infrastructure in the build system, so I'm going to need > help with that... With the idea of contributing the script back to Automake for use in its lib_LIBRARIES rules, we shouldn't use the m4sh infrastructure, so let's just encapsulate it in a self-contained script to be installed alongside mdate-sh, depcomp and the like. It looks pretty straight- forward actually. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: pr-msvc-support merge
Den 2010-06-10 11:14 skrev Gary V. Vaughan: 8c17887ee34e73a2aeb127b94f5b76f45dc34017 Why so much cruft in ltmain.m4sh just to drive a different archiver? It seems to me that this would be better and easier to maintain, test and extend as a whole new script. Let's call it, $prefix/libexec/libtool/ar, build it from $srcdir/libltdl/config/ar.m4sh, and have libtool set AR to point at the script instead of /usr/bin/ar when the system is funky. WDYT? Sound appealing! I didn't want libtool to mess with $AR, so I introduced another layer of indirection through a new $LTAR variable that libtool can set to the "libtool --mode=ar" fallback for funky archivers. My way requires interaction with automake but that's not needed if there's no problem with libtool messing with $AR. Well, I think we'll need a parallel patch for automake anyway, since automake has lib_LIBRARIES which may very well call $AR without involving libtool at all. Which makes me think that once we have our wrapper working, it makes more sense to contribute it to automake than release it with libtool. If the libtool part of the configure script clobbers $AR with the wrapper script when needed, Automake can call $AR as much as it likes and it will work. Or what am I missing? I have a patch somewhere that adds tracing to make all available libtool modes detectable by automake and a 'tiny' automake patch somewhere else that uses that to determine if the extra layer of indirection is available, should I go digging for those patches or is "my way" just too ugly? I dunno. It's not the way I would have done it, but in the end you've done all the work, and you'll likely be the one who keeps it all working in the face of other changes to libtool down the line. So you get to choose whether you'd like to put more work in up front to minimise the amount of maintenance you need later on. Your call entirely :) Hmmm, the extra layer of indirection is orthogonal, isn't it? I'm not sure exactly what you mean. Certainly we (and eventually Automake) will need to figure out what to put in AR, but while we get it working, I see no harm in unconditionally using: 'AR = $(auxdir)/ar' What I mean is that $AR may have been set by the user before running configure to make a specific selection of the archiver. If the configure script then determines that the user-provided $AR needs wrapping, it needs to store this fact somewhere, and then you have contention for the AR name. Is $AR under the control of the user or the configure script? However, I guess the situation is very much the same as with $CC and the compile script and that seems to work. I just don't understand exactly how. Does it work because the CC make variable is not the same thing as the CC shell variable? *looks around a bit* No, that's not it, one instance of the libtool script has CC="/c/cygwin/home/peda/libtool/git/libtool-msvc/libltdl/config/compile cl" and I only said CC=cl when I configured... Maybe this is a non-issue? You should know that this ar wrapper thing is an alternative to commit 0bb52ed03e71109ef75f8d72439ea1365ae14f42 with the core idea to use a new variable $AR_SEP to handle some of the funkiness of the MS archiver. The problem with that is that $AR_SEP needs to be a space in the normal case, and a single space is not easily stored as the variable content in makefiles. I think we get to sidestep that whole issue by having the ar wrapper figure it out at runtime for the best flexibility and reusability of the same script when jumping between cygwin/msys/mingw etc. > Your way is also a bit over the top of my head. I don't know how to create the infrastructure in the build system, so I'm going to need help with that... With the idea of contributing the script back to Automake for use in its lib_LIBRARIES rules, we shouldn't use the m4sh infrastructure, so let's just encapsulate it in a self-contained script to be installed alongside mdate-sh, depcomp and the like. It looks pretty straight- forward actually. Hmm, does this mean that everything about getting support for MS lib as archiver ends up in Automake? One thing that I "fear" about not having the support built into libtool is that projects might need to invoke some extra macro (copy-paste-fix AM_PROG_CC_C_O). Old projects tend to have AM_PROG_CC_C_O since they needed to support some oldish toolchain many years ago, but how many maintainers are going to add AM_PROG_FUNKY_AR and the $auxdir/ar script at this point? Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] [PATCH] libltdl error reporting
Aside: I'm leaning away from upholding the 'drop-in-with-minimum-edits' philosophy for my rewrite, since the dlfcn.h API seems like a pretty bad design to me. After all, all people really need to do is call functions with a known name and known signature which happen to be in another library. I'm seriously contemplating using a *much* smaller and cleaner API, which ends up with client code more along the lines of: With that as a starting point, it's easy enough to maintain an error stack in an exception struct that wraps around setjmp/longjmp, and to plus some glue to make catching an error thrown from libltdl2 and for unwinding the error stack inside it as easy as possible. WDYT? I think it would be better in c++. I am unsure that a rewrite is necessary though. Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: pr-msvc-support merge
Hi Peter, On 10 Jun 2010, at 20:55, Peter Rosin wrote: > Den 2010-06-10 11:14 skrev Gary V. Vaughan: >8c17887ee34e73a2aeb127b94f5b76f45dc34017 Why so much cruft in ltmain.m4sh just to drive a different archiver? It seems to me that this would be better and easier to maintain, test and extend as a whole new script. Let's call it, $prefix/libexec/libtool/ar, build it from $srcdir/libltdl/config/ar.m4sh, and have libtool set AR to point at the script instead of /usr/bin/ar when the system is funky. WDYT? >>> >>> Sound appealing! I didn't want libtool to mess with $AR, so I introduced >>> another layer of indirection through a new $LTAR variable that libtool >>> can set to the "libtool --mode=ar" fallback for funky archivers. My way >>> requires interaction with automake but that's not needed if there's no >>> problem with libtool messing with $AR. >> >> Well, I think we'll need a parallel patch for automake anyway, since automake >> has lib_LIBRARIES which may very well call $AR without involving libtool at >> all. >> >> Which makes me think that once we have our wrapper working, it makes more >> sense to contribute it to automake than release it with libtool. > > If the libtool part of the configure script clobbers $AR with the wrapper > script when needed, Automake can call $AR as much as it likes and it will > work. Or what am I missing? I'm thinking about people who'lll need a wrapped AR from automake to build lib_LIBRARIES (as opposed to lib_LTLIBRARIES) when the project doesn't want to use libtool at all. Or maybe that makes no sense for a Windows build? >>> Hmmm, the extra layer of indirection is orthogonal, isn't it? >> >> I'm not sure exactly what you mean. Certainly we (and eventually >> Automake) will need to figure out what to put in AR, but while we >> get it working, I see no harm in unconditionally using: >> >> 'AR = $(auxdir)/ar' > > What I mean is that $AR may have been set by the user before running > configure to make a specific selection of the archiver. If the configure > script then determines that the user-provided $AR needs wrapping, it > needs to store this fact somewhere, and then you have contention for > the AR name. Is $AR under the control of the user or the configure > script? Oh, I see. AR is a user variable, and in that respect we should trust that the user knows what they're doing if they set AR to something specific on purpose. > However, I guess the situation is very much the same as with > $CC and the compile script and that seems to work. I just don't > understand exactly how. Does it work because the CC make variable is > not the same thing as the CC shell variable? > > *looks around a bit* > > No, that's not it, one instance of the libtool script has > > CC="/c/cygwin/home/peda/libtool/git/libtool-msvc/libltdl/config/compile cl" > > and I only said CC=cl when I configured... I don't know how it works either, but I think you're right to mirror the way automake handles CC. Hopefully Eric or Ralf will jump in and correct me if I'm off base. >>> Your way is also a bit over the top of my head. I don't know how to >>> create the infrastructure in the build system, so I'm going to need >>> help with that... >> >> With the idea of contributing the script back to Automake for use in >> its lib_LIBRARIES rules, we shouldn't use the m4sh infrastructure, so >> let's just encapsulate it in a self-contained script to be installed >> alongside mdate-sh, depcomp and the like. It looks pretty straight- >> forward actually. > > Hmm, does this mean that everything about getting support for MS lib > as archiver ends up in Automake? Mostly, but libtool will make use of it too in projects that use both. And I think that libtool should pull the latest copy and distribute it in it's release tarballs too, since we also want libtool to be useful in non-automake projects (even non-Autoconf projects actually). > One thing that I "fear" about not having the support built into libtool > is that projects might need to invoke some extra macro (copy-paste-fix > AM_PROG_CC_C_O). Old projects tend to have AM_PROG_CC_C_O since they > needed to support some oldish toolchain many years ago, but how many > maintainers are going to add AM_PROG_FUNKY_AR and the $auxdir/ar script > at this point? From (what I remember of) the inner workings of Automake, it's not difficult to teach the automake invocation to notice the use of _LIBRARIES or _LTLIBRARIES as it scans the Makefile.ams, and then AC_REQUIRE the necessary macros from AM_INIT_AUTOMAKE. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] [PATCH] libltdl error reporting
Hi Peter, On 10 Jun 2010, at 21:15, Peter O'Gorman wrote: >> Aside: I'm leaning away from upholding the >> 'drop-in-with-minimum-edits' philosophy for my rewrite, since the >> dlfcn.h API seems like a pretty bad design to me. After all, all >> people really need to do is call functions with a known name and >> known signature which happen to be in another library. I'm seriously >> contemplating using a *much* smaller and cleaner API, which ends up >> with client code more along the lines of: [[...]] >> >> With that as a starting point, it's easy enough to maintain an error >> stack in an exception struct that wraps around setjmp/longjmp, and to > >> plus some glue to make catching an error thrown from libltdl2 and for >> unwinding the error stack inside it as easy as possible. WDYT? > > I think it would be better in c++. No, that would mean you have to jump through hoops to use it from C. And it would make me cry myself to sleep at night. I avoid C++, Perl, McDonalds and suicide bomber recruiters as much as I possibly can. I'm still undecided as to which one is worst for your health... > I am unsure that a rewrite is necessary though. For me to get any further than I have already, without making things even uglier than they already are, rearchitecting the whole thing seems like the best way to learn from the mistakes of the 12 year old incumbent implementation. Otherwise I end up staring at it, and spending whole weekends trying to understand why it handed back another useless file-not-found error. ;) Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rewrite of ltdl and c++ (was: Re: [RFC] [PATCH] libltdl error reporting)
On 06/10/2010 09:45 AM, Gary V. Vaughan wrote: I think it would be better in c++. No, that would mean you have to jump through hoops to use it from C. And it would make me cry myself to sleep at night. I avoid C++, Perl, McDonalds and suicide bomber recruiters as much as I possibly can. I'm still undecided as to which one is worst for your health... It's simple to write a library in C++ but make its public interface C. There are many projects that use what I would describe as sane C++ (unfortunately there are also many that use every possible feature). IMO, setjmp/longjmp is significantly uglier. But, let's end this debate, it's unlikely to lead to anything productive :) Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: rewrite of ltdl and c++
Hello, * Peter O'Gorman wrote on Thu, Jun 10, 2010 at 05:12:41PM CEST: > On 06/10/2010 09:45 AM, Gary V. Vaughan wrote: > >>I think it would be better in c++. > > > >No, that would mean you have to jump through hoops to use it from C. > It's simple to write a library in C++ but make its public interface > C. There are many projects that use what I would describe as sane > C++ (unfortunately there are also many that use every possible > feature). Linking a C-only project against a C++ library is quite error-prone if you only use the C compiler. I'm with Gary here. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] [PATCH] libltdl error reporting
On 06/10/2010 02:28 PM, Bob Friesenhahn wrote:
On Thu, 10 Jun 2010, Peter O'Gorman wrote:
As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like "file not found" where the
actual problem might be something completely different, and a
reasonable error string may be readily available from dlerror().
As we have known for quite a while now, libltdl's error reporting is not
sane. For example, the preloader always issues a useless error ("file
not found") when preloading is not used for the module. Since the
loaders were nicely modularized, each loader is tried in turn (issuing
an error on failure) until a loader is successful, or there are no more
loaders. This is perhaps worse on OS-X where there are two OS APIs for
loading modules. I think that some improvements were made, but
functionality is still lacking.
The patch that I attached should solve most of those issues. On Mac OS
X, the dyld loader is not built if dlopen is available, if I remember
correctly.
Peter
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] [PATCH] libltdl error reporting
On Thu, 10 Jun 2010, Peter O'Gorman wrote:
As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like "file not found" where the actual
problem might be something completely different, and a reasonable error
string may be readily available from dlerror().
As we have known for quite a while now, libltdl's error reporting is
not sane. For example, the preloader always issues a useless error
("file not found") when preloading is not used for the module. Since
the loaders were nicely modularized, each loader is tried in turn
(issuing an error on failure) until a loader is successful, or there
are no more loaders. This is perhaps worse on OS-X where there are
two OS APIs for loading modules. I think that some improvements were
made, but functionality is still lacking.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: pr-msvc-support merge
Hello, * Gary V. Vaughan wrote on Thu, Jun 10, 2010 at 04:35:41PM CEST: > On 10 Jun 2010, at 20:55, Peter Rosin wrote: > > However, I guess the situation is very much the same as with > > $CC and the compile script and that seems to work. I just don't > > understand exactly how. That's pretty much an awful hack inside AM_PROG_CC_C_O, which overrides $CC if need be. > > Does it work because the CC make variable is > > not the same thing as the CC shell variable? > > > > *looks around a bit* > > > > No, that's not it, one instance of the libtool script has > > > > CC="/c/cygwin/home/peda/libtool/git/libtool-msvc/libltdl/config/compile cl" > > > > and I only said CC=cl when I configured... > > I don't know how it works either, but I think you're right to mirror > the way automake handles CC. Hopefully Eric or Ralf will jump in and > correct me if I'm off base. See above. It'd be nice to not have many more of those, if we can help it; but it seems to not bother too many users in practice, and if it's confined to MSVC ... > >>> Your way is also a bit over the top of my head. I don't know how to > >>> create the infrastructure in the build system, so I'm going to need > >>> help with that... > >> > >> With the idea of contributing the script back to Automake for use in > >> its lib_LIBRARIES rules, we shouldn't use the m4sh infrastructure, so > >> let's just encapsulate it in a self-contained script to be installed > >> alongside mdate-sh, depcomp and the like. It looks pretty straight- > >> forward actually. This sounds like a good idea to me. > > Hmm, does this mean that everything about getting support for MS lib > > as archiver ends up in Automake? > > Mostly, but libtool will make use of it too in projects that use both. > And I think that libtool should pull the latest copy and distribute it > in it's release tarballs too, since we also want libtool to be useful > in non-automake projects (even non-Autoconf projects actually). That sounds good to me, too. It's just that if you need to transport information from configure to such a script that things get a bit hairy. We do it with 'depcomp' by setting variables in the commands that run it, but IIUC you would prefer that makefiles continue to work without changes. > > One thing that I "fear" about not having the support built into libtool > > is that projects might need to invoke some extra macro (copy-paste-fix > > AM_PROG_CC_C_O). Old projects tend to have AM_PROG_CC_C_O since they > > needed to support some oldish toolchain many years ago, but how many > > maintainers are going to add AM_PROG_FUNKY_AR and the $auxdir/ar script > > at this point? > > From (what I remember of) the inner workings of Automake, it's not > difficult to teach the automake invocation to notice the use of > _LIBRARIES or _LTLIBRARIES as it scans the Makefile.ams, and then > AC_REQUIRE the necessary macros from AM_INIT_AUTOMAKE. Right. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
