From: Alan W. I. <ir...@be...> - 2002-11-25 07:12:39
|
OK. I answered my own questions empirically. Turned out that lt_ptr_t was obsolete (shows how quickly things have moved since autotools book), and according to info pages for libtool version 1.4.2, lt_ptr should be used instead. After I fixed that problem, here are the answers I discovered by seeing whether the build, install, and x08c test worked. (1) is correct. (2) should be changed to typedef lt_ptr (*PLDispatchInit)( PLDispatchTable *pdt ); Any C expert on the list know why *PLDispatchInit rather than PLDispatchInit? I naively thought you would drop the asterisk because the type was going from void * to lt_ptr, but as you all know, my C programming skills are not the best especially when dealing with pointers and complicated typedefs. The example of typedef on p. 147 of the little white K&R book is analogous to this one, but I don't understand the point of (*PFI) rather than (PFI) in that case as well. One other issue I ran into was how to initialize libltdl and release its memory when done. Same old problem (mentioned in the plcore.c comments) of no clear PLplot library initialization . So I chose to do the initialize whenever a stream was created and release whenever it was destroyed. This is overcomplicated, and it would be better to initialize just once before any streams are created and release after they are all destroyed, but there is no clear way to tell when plinit is first called so I had to do it stream by stream. A final issue was the top-level aclocal.m4 was one of those deleted files that Rafael accidentally included during his merge from MAIN to AM-LT. I deleted that file from the AT branch since a new version of it (not a 7-yr old version!) is automatically generated by one of the commands in bootstrap.sh. Anyhow, after those changes (just now committed) the AT cookbook just worked again. Also, a valgrind test of ./x08c -dev psc -o test.ps revealed no new problems beyond what I have reported before. Next step (tomorrow) is to try all this on a solaris platform to see if there are any obvious cross-platform issues with dynamic drivers (or anything else) there. I will be following Rafael's old cookbook on making a tarball to try out on solaris. The neat thing about this approach is nothing will be needed on the solaris machine other than a working compiler, and the solaris version of scripting and make. Once that is sorted out, the next steps are to try the tarball results of the AT branch on as many platforms as the other developers here have access to while I concentrate on expanding to more than the xwin and ps drivers that are working now and more front ends than just the C front end that is working now. Once we have at least the current CVS HEAD functionality on the AT branch (all dynamic drivers and all front ends working) with the addition of cross-platform capability, I will want to merge the AT branch into CVS HEAD. The AT effort is going much faster than I thought (because of the great start by Rafael and because autotools is pretty easy to learn from scratch) so the merge to HEAD *could* happen soon (i.e., maybe even sometime during this week unless I run into unforseen problems.) So I suggest you should get involved immediately if you want to evaluate the AT approach before the merge! Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ ---------- Forwarded message ---------- Date: Sun, 24 Nov 2002 13:36:25 -0800 (PST) From: Alan W. Irwin <ir...@uv...> To: PLplot development list <Plp...@li...> Cc: Rafael Laboissiere <lab...@ps...> Subject: [Plplot-devel] Quick help needed with changing a struct and a typedef in PLplot I start with the background information that is required on the dlopen to libltdl API change, then get to my two "simple" numbered questions at the end which any C expert should be able to answer for me. For the AT branch I am in the middle of changing from the dlopen API to the libltdl API to increase cross-platform compatibility. The old API: void * dlopen (const char *filename, int flag) void * dlsym (void *handle, char *name) int dlclose (void *handle) const char * dlerror (void) The new API: lt_dlhandle lt_dlopen (const char *filename) lt_dlhandle lt_dlopenext (const char *filename) lt_ptr_t lt_dlsym (lt_dlhandle handle, const char *name) int lt_dlclose (lt_dlhandle handle) const char * lt_dlerror (void) Note: lt_dlopenext is the same as lt_dlopen except that it tries with alternate suffixes if there is not an exact match to the name. In the new plcore.c there is the following line: driver->dlhand = lt_dlopenext( drvspec); which replaces the old driver->dlhand = dlopen( drvspec, flag); Subsequently driver->dlhand is used as an argument to lt_dlsym So in plplot.h I have changed from typedef struct { char *drvnam; void *dlhand; } PLLoadableDriver; to typedef struct { char *drvnam; lt_dlhandle dlhand; } PLLoadableDriver; With appropriate #include of the libltdl header and protection by #ifdef ENABLE_DYNDRIVERS. (1) Is that change to the struct the correct thing to do for the changed API? (2) The new plcore.c code also has the following fragment: PLDispatchInit dispatch_init = lt_dlsym( driver->dlhand, sym ); where the old disptab.h has typedef void (*PLDispatchInit)( PLDispatchTable *pdt ); What should I change that typedef to? My guess is something like typedef lt_ptr_t (PLDispatchInit)( PLDispatchTable *pdt ); but I am not completely sure so any quick help would be much appreciated. Of course I am going to try some variations on this theme this afternoon and hopefully get something to work, but the definitive answer would be most useful. C typedefs and pointers just plain drive me crazy! Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Plplot-devel mailing list Plp...@li... https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Maurice L. <mj...@ga...> - 2002-11-26 19:15:25
|
Alan W. Irwin writes: > (2) should be changed to > typedef lt_ptr (*PLDispatchInit)( PLDispatchTable *pdt ); > > Any C expert on the list know why *PLDispatchInit rather than > PLDispatchInit? I naively thought you would drop the asterisk because the > type was going from void * to lt_ptr, but as you all know, my C programming > skills are not the best especially when dealing with pointers and > complicated typedefs. The example of typedef on p. 147 of the little white > K&R book is analogous to this one, but I don't understand the point of > (*PFI) rather than (PFI) in that case as well. It looks to me you're going from a void (not void*) to lt_ptr, since the original typedef was: typedef void (*PLDispatchInit)( PLDispatchTable *pdt ); The new typedef: typedef lt_ptr (*func)( PLDispatchTable *pdt ); allows you to declare a function pointer in the following way: func dispatch_init; which means that: dispatch_init is a pointer to a function that passes a pointer to a PLDispatchTable and returns lt_ptr. It doesn't matter what "func" is called, in this case PLDispatchInit. One confusing point is that ANSI C allows you to drop the explicit dereference when making the actual function call, i.e. (*dispatch_init)(pdt); and dispatch_init(pdt); are the same. But since you have to keep the distinction straight in the declaration, the first form is probably better (IMO) as being more transparent. > One other issue I ran into was how to initialize libltdl and release its > memory when done. Same old problem (mentioned in the plcore.c comments) of > no clear PLplot library initialization . So I chose to do the initialize > whenever a stream was created and release whenever it was destroyed. This > is overcomplicated, and it would be better to initialize just once before > any streams are created and release after they are all destroyed, but there > is no clear way to tell when plinit is first called so I had to do it stream > by stream. Could it go in pllib_init()? I added this earlier this year to help solve this problem -- any routine the user might call first (if I didn't miss any) calls this first to do library initialization. > The AT effort is going much faster than I thought (because of the great > start by Rafael and because autotools is pretty easy to learn from scratch) > so the merge to HEAD *could* happen soon (i.e., maybe even sometime during > this week unless I run into unforseen problems.) So I suggest you should get > involved immediately if you want to evaluate the AT approach before the > merge! Will try, but am very very busy. I appreciate all your effort on this tho. > Alan -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-11-26 23:04:14
|
On Tue, 26 Nov 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > Any C expert on the list know why *PLDispatchInit rather than > > PLDispatchInit? > [...]One confusing point is that ANSI C allows you to drop the explicit dereference > when making the actual function call, i.e. > > (*dispatch_init)(pdt); > and > dispatch_init(pdt); > > are the same. But since you have to keep the distinction straight in the > declaration, the first form is probably better (IMO) as being more > transparent. Thanks, Maurice. I was indeed getting confused by that. Thanks for the explanation! > > One other issue I ran into was how to initialize libltdl and release its > > memory when done. > > Could it go in pllib_init()? I added this earlier this year to help solve > this problem Yes, that is an excellent solution which I have just tested and committed. Thanks! Alan |