From: Maurice L. <mj...@ga...> - 2002-01-20 10:14:18
|
My last round of commits fixed all the config problems I mentioned previously. Please try it out. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-01-21 08:38:03
|
On Sun, 20 Jan 2002, Maurice LeBrun wrote: > My last round of commits fixed all the config problems I mentioned > previously. Thanks, Maurice. > Please try it out. The results of the near-default ./configure --disable-java --without-shlib that I did for Joao seemed to be fine. (In fact too fine because I could not reproduce his problem.) I also tried ./configure --disable-drivers --enable-png --enable-dyndrivers and I got devices: png jpeg cgm xwin tk Available device drivers static: xwin tk dynamic: gd cgm All these devices worked fine, but I don't understand why --disable-drivers is not affecting cgm. I worked really hard to make all the cgm stuff in plplot/cf/*.in files identical to what was done for gd or png/jpeg as appropriate. Also, I just checked that again, and I cannot find anything. Nevertheless something is wrong for cgm (and perhaps also for jpeg and png or gd since cgm follows them), and I hope you find it. Perhaps there is a more mundane reason why xwin and tk are still there despite the --disable-drivers option, but again I don't understand this. (I tried the same thing with default static drivers and got the same result, all 5 devices were available.) Finally, I tried a super-kill of everything but device png. configure --disable-drivers --disable-jpeg --disable-cgm \ --disable-tk --disable-xwin --enable-png --enable-dyndrivers That worked to isolate just the png device for the gd driver with none of the other 4 devices that were active before, but I don't see why a simple --disable-drivers wouldn't have given the same thing. Finally, I noticed the following compilation messages for the first configuration (but none of the others, interestingly). tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp' tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp' plframe.o(.text+0x291d): the use of tmpnam' is dangerous, better use mkstemp' I suspect this message means our use of tmpnam is opening a security hole. I don't know how serious this is, but, Maurice, if you know how to use mkstemp then you may want to switch to it from tmpnam. Alan |
From: Maurice L. <mj...@ga...> - 2002-01-21 11:23:42
|
Alan W. Irwin writes: > On Sun, 20 Jan 2002, Maurice LeBrun wrote: > I also tried > > ./configure --disable-drivers --enable-png --enable-dyndrivers > > and I got > > devices: png jpeg cgm xwin tk > > Available device drivers > static: xwin tk > dynamic: gd cgm > > All these devices worked fine, but I don't understand why --disable-drivers > is not affecting cgm. ... It's because of the following lines in configure.in, near the top: #explicit default values must be specified here for library and header #searching to work right for the following variables. Note these variables #also have a driver role to play, but unlike these, pure-driver variables #(e.g., enable_tek4010) do not require a default to be specified here. enable_gnome=no enable_ntk=no enable_png=yes enable_jpeg=yes enable_cgm=yes enable_tk=yes enable_xwin=yes --disable-drivers only sets the default to "no", and doesn't override any explicitly enabled devices, which these are (equivalent to command line settings). Apparently they do serve a purpose for getting library linkage right under Linux -- I just tried without them and the build failed (to my surprise). There may be a better way to fix it, I dunno. But anyway apparently works as expected. You can always use explicit disabling of devices, which I do, from my ~/config/cf_plplot.in file. > Finally, I noticed the following compilation messages for the first > configuration (but none of the others, interestingly). > > tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp' > tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp' > plframe.o(.text+0x291d): the use of tmpnam' is dangerous, better use mkstemp' > > I suspect this message means our use of tmpnam is opening a security hole. > I don't know how serious this is, but, Maurice, if you know how to use > mkstemp then you may want to switch to it from tmpnam. Theoretically there is a problem, but I'm not worrying about it. tmpnam is POSIX, mkstemp is not. Maybe eventually I'll do some configure stuff to use mkstemp where available, otherwise tmpnam, just to shut up gcc. But not that important to me. -- Maurice LeBrun mj...@ga... |
From: Alan W. I. <ir...@be...> - 2002-01-21 16:13:52
|
On Mon, 21 Jan 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > All these devices worked fine, but I don't understand why --disable-drivers > > is not affecting cgm. ... > > It's because of the following lines in configure.in, near the top: > > #explicit default values must be specified here for library and header > #searching to work right for the following variables. Note these variables > #also have a driver role to play, but unlike these, pure-driver variables > #(e.g., enable_tek4010) do not require a default to be specified here. > enable_gnome=no > enable_ntk=no > enable_png=yes > enable_jpeg=yes > enable_cgm=yes > enable_tk=yes > enable_xwin=yes > > --disable-drivers only sets the default to "no", and doesn't override any > explicitly enabled devices, which these are (equivalent to command line > settings). Apparently they do serve a purpose for getting library linkage > right under Linux -- I just tried without them and the build failed (to my > surprise). There may be a better way to fix it, I dunno. But anyway > apparently works as expected. You can always use explicit disabling of > devices, which I do, from my ~/config/cf_plplot.in file. I woke up this morning (apparently close to when you finished working hard all night.... thanks!) with the same idea that it had something to do with the extra library configuration that occurs for certain drivers. Thanks for investigating further to determine this special configuration was still necessary. I agree, let's continue to live with it. > > tk.o(.text+0x1c70): the use of tmpnam' is dangerous, better use mkstemp' > > > > I suspect this message means our use of tmpnam is opening a security hole. > > I don't know how serious this is, but, Maurice, if you know how to use > > mkstemp then you may want to switch to it from tmpnam. > > Theoretically there is a problem, but I'm not worrying about it. tmpnam is > POSIX, mkstemp is not. Maybe eventually I'll do some configure stuff to use > mkstemp where available, otherwise tmpnam, just to shut up gcc. But not that > important to me. Thanks for looking into this. STATUS QUESTION: So is there anything left on our plates other than the fortran problems that Joao has found? (BTW, I view that bug as serious. For now, Joao has to deal with this bug on his own. Since I cannot reproduce it on my system, I am reduced to helping him only with guess work. Those with some fortran knowledge, please do take a few minutes to attempt reproducing the bug on your systems on the off chance that you can give him some help to solve this quickly.) Alan |
From: Geoffrey F. <fu...@ga...> - 2002-01-21 16:36:43
|
Alan W. Irwin writes: > STATUS QUESTION: > > So is there anything left on our plates other than the fortran problems that > Joao has found? Well, uhh, here's a couple of things on my mind. 1) I'm not really done with the plshade api wrappers for Java. I just did the double with no coord xforms, needed for x15.java. If you implement the other java demos (16 and 18), I'll have some more api work to do to get them displaying, and even if not, I kinda need to at least do the float prec version of what I did Friday night for one of the double cases. Will /try/ to do this today, but would appreciate being allowed to slipstream some changes to javabind.c in later if I can't get it done before 8 am tomorrow. Doubt I'll be hacking from home tonight. 2) I just found that I can't run configure on a slowaris box. That seems significant to me, and I'll be looking into it now. |
From: Geoffrey F. <fu...@ga...> - 2002-01-21 16:50:32
|
Geoffrey Furnish writes: > 2) I just found that I can't run configure on a slowaris box. That > seems significant to me, and I'll be looking into it now. The problem is near the top: with_defaults=yes for option; do case "$option" in -with-defaults | --with-defaults | -with-defaults=yes | --with-defaults=yes ) with_defaults=yes ;; -without-defaults | --without-defaults | -with-defaults=no | --with-defaults=no ) with_defaults=no ;; esac done Sun sh flips out saying the ; after "option" in the for clause, is unexpected. Yet Sun man sh says: for name [ in word ... ] do list done Each time a for command is executed, name is set to the next word taken from the in word list. If in word ... is omitted, then the for command exe- cutes the do list once for each positional parame- ter that is set (see Parameter Substitution sec- tion below). Execution ends when there are no more words in the list. But, evidently, it doesn't actually work as documented. I'm cahnging this to: for option in $*; do which it seems to accept. Sheesh. This is a Sunos 5.7 box, fyi. -- Geoffrey Furnish fu...@ga... |
From: Alan W. I. <ir...@be...> - 2002-01-21 18:12:41
|
On Mon, 21 Jan 2002, Geoffrey Furnish wrote: > Alan W. Irwin writes: > > STATUS QUESTION: > > > > So is there anything left on our plates other than the fortran problems that > > Joao has found? > > Well, uhh, here's a couple of things on my mind. > > 1) I'm not really done with the plshade api wrappers for Java. I just > did the double with no coord xforms, needed for x15.java. If you > implement the other java demos (16 and 18), I'll have some more api > work to do to get them displaying, and even if not, I kinda need to at > least do the float prec version of what I did Friday night for one of > the double cases. Will /try/ to do this today, but would appreciate > being allowed to slipstream some changes to javabind.c in later if I > can't get it done before 8 am tomorrow. Doubt I'll be hacking from > home tonight. I have a conflict of interest here between my interest in seeing more work done on the Java API and my release/testing manager role. Also, I am well aware I put you in the soup by doing so many java template changes late with perhaps even more to come today. But I consider java to be "experimental" until all the API is complete. Since there is no chance of that happening for this release, I think that takes all the pressure off to jam in more API at the last minute before the release. Also, I would rather have you configuration debugging on solaris, see below. Also, while I am testing on Tuesday and Wednesday my plate will be absolutely full so I would prefer no distractions. Thus, weighing everything up I would feel most comfortable if we stick to the Tuesday morning deadline for the soft freeze. So if you can do a bit more today on java (after you are happy with solaris configuration) that would be great, but if not, that is fine as well. That is exactly the same low-pressure approach I am taking to my own last-minute work on the example unification today. > > 2) I just found that I can't run configure on a slowaris box. That > seems significant to me, and I'll be looking into it now. From your subsequent posts, it sounds like you solved this problem but are still working on another solaris configuration problem. I *really* appreciate this work because it means I am not going to be sandbagged when I attempt to build and test on the compile farm solaris machine. Looking forward to your configuration commit. Alan |
From: Geoffrey F. <fu...@ga...> - 2002-01-21 17:07:30
|
Geoffrey Furnish writes: > Alan W. Irwin writes: > > STATUS QUESTION: > > > > So is there anything left on our plates other than the fortran problems that > > Joao has found? > > Well, uhh, here's a couple of things on my mind. > > 2) I just found that I can't run configure on a slowaris box. That > seems significant to me, and I'll be looking into it now. Well, I was on a slowaris box just to see if I could duplicate Joao's problem with Fortran. We have a g77 here called: > g77 -v g77 version 2.95.2 19991024 (release) (from FSF-g77 version 0.5.25 19991024 (release)) which I was hoping would be similar enough to Joao's to show the problem (albeit this is a solaris build, not Linux). However, I experience no problem: m4 -S2000 -B8192 x06f.fm4 >x06f.f g77 -c -O x06f.f g77 x06f.o \ -L. -lplplot -ltclmatrix -o x06f -L/usr/local/lib -ltk8.2 -ltcl8.2 -lX11 -ldl m4 -S2000 -B8192 x07f.fm4 >x07f.f g77 -c -O x07f.f g77 x07f.o \ -L. -lplplot -ltclmatrix -o x07f -L/usr/local/lib -ltk8.2 -ltcl8.2 -lX11 -ldl And the examples work as expected. OTOH, I did learn that PLplot's configure support for Solaris leaves a lot to be desired. Besides the problem with shell syntax, it also somehow dropped -lm from all the link lines, causing every C prog link to fail (but notice that the f77 links above all worked). -- Geoffrey Furnish fu...@ga... |
From: Geoffrey F. <fu...@ga...> - 2002-01-21 19:14:15
|
Geoffrey Furnish writes: > OTOH, I did learn that PLplot's configure support for Solaris leaves a > lot to be desired. Besides the problem with shell syntax, it also > somehow dropped -lm from all the link lines, causing every C prog link > to fail (but notice that the f77 links above all worked). I've done about all I can stand to fix various configure bugs for now. Solaris is always a touchy situation. I have one solaris box here where CC is detected by PLplot configure, but cc doesn't work, and that causes all kinds of horrific screwups downstream. I dunno, maybe we should someday think to improve the compiler detection to check for a "working compiler", not merely a compiler seen in the path. Sheesh, I can't imagine how Sun has stayed in business all these years. Anyway, I have another Solaris box where the cc works, also with KCC and g77. On this box, I've been able to test SMP builds for C, C++ and F77 components, and everything seems to work, including we now use KCC to form .a's as well as .so's. Well, on Linux we use KCC to form .so's, but on Solaris we don't support shared libs at this time. I s'pose we shoudl come back and fix /that/ one of these days too, but not today. :-). So, I'd call the current CVS head the most stable, correct PLplot I've seen in a while. Great work, everybody. BTW, compiling with Sun cc is I suppose, what Alan was really driving at earlier. I'm not inclined to worry about POSIX-but-not-ANSI stuff in PLplot. Maurice and I went through that argument years ago. I think the main thing is we need to keep extension syntax out of the code base, and the current sources seem to do that well enough. -- Geoffrey Furnish fu...@ga... |
From: Alan W. I. <ir...@be...> - 2002-01-21 19:37:08
|
On Mon, 21 Jan 2002, Geoffrey Furnish wrote: > Geoffrey Furnish writes: > > OTOH, I did learn that PLplot's configure support for Solaris leaves a > > lot to be desired. Besides the problem with shell syntax, it also > > somehow dropped -lm from all the link lines, causing every C prog link > > to fail (but notice that the f77 links above all worked). > > I've done about all I can stand to fix various configure bugs for > now. > > Solaris is always a touchy situation. I have one solaris box here > where CC is detected by PLplot configure, but cc doesn't work, and > that causes all kinds of horrific screwups downstream. I dunno, maybe > we should someday think to improve the compiler detection to check for > a "working compiler", not merely a compiler seen in the path. Sheesh, I ran into this solaris problem also (in the 5.0.3, era, I believe), and the solution was to put the directory with the working (!) cc higher in the path than the directory for the non-working one. > I can't imagine how Sun has stayed in business all these years. I can't imagine either. > > Anyway, I have another Solaris box where the cc works, also with KCC > and g77. On this box, I've been able to test SMP builds for C, C++ > and F77 components, and everything seems to work, including we now use > KCC to form .a's as well as .so's. > [...] So, I'd call the current CVS head the most stable, correct PLplot I've > seen in a while. > > Great work, everybody. Seconded! > > BTW, compiling with Sun cc is I suppose, what Alan was really driving > at earlier. Yes, sun/solaris compilation problems were the number one bug report for 5.0.4. It looks like we will avoid that this time (assuming our solaris users can find a working compiler!) Alan |
From: Joao C. <jc...@fe...> - 2002-01-21 19:02:45
|
On Monday 21 January 2002 4:50 pm, Geoffrey Furnish wrote: > Geoffrey Furnish writes: > > 2) I just found that I can't run configure on a slowaris box. That > > seems significant to me, and I'll be looking into it now. > > The problem is near the top: > > with_defaults=3Dyes > for option; do > case "$option" in > -with-defaults | --with-defaults | -with-defaults=3Dyes | > --with-defaults=3Dyes ) > =09=09 with_defaults=3Dyes > =09=09=09;; > =09=09=09-without-defaults | --without-defaults | > -with-defaults=3Dno | --with-defaults=3Dno ) > =09=09 with_defaults=3Dno > =09=09 ;; > esac > done > > Sun sh flips out saying the ; after "option" in the for clause, is > unexpected. Yet Sun man sh says: > > for name [ in word ... ] do list done > Each time a for command is executed, name is set > to the next word taken from the in word list. If > in word ... is omitted, then the for command exe- > cutes the do list once for each positional parame- > ter that is set (see Parameter Substitution sec- > tion below). Execution ends when there are no more > words in the list. > > But, evidently, it doesn't actually work as documented. I'm cahnging > this to: > > for option in $*; do > > which it seems to accept. Sheesh. > > This is a Sunos 5.7 box, fyi. This also happens on an OSF1 alpha. Your solution also works here (but it= is=20 not yet cvs commited, isn't it?). But, after 'make' =2E.. ar: Warning: creating libplplot.a ranlib libplplot.a cc -std -c -O1 -I. plrender.c cc -std plrender.o -L. -lplplot -o plrender -lX11 -lm=20 ld: Unresolved: plD_dispatch_init_xw plD_dispatch_init_xterm plD_dispatch_init_tekt plD_dispatch_init_tek4107t plD_dispatch_init_mskermit =2E.. A plain ./configure was issued, and no dynamic libs was built. Joao |
From: Geoffrey F. <fu...@ga...> - 2002-01-21 19:07:21
|
Joao Cardoso writes: > This also happens on an OSF1 alpha. Your solution also works here (but it is > not yet cvs commited, isn't it?). > > But, after 'make' > > ... > ar: Warning: creating libplplot.a > ranlib libplplot.a > > cc -std -c -O1 -I. plrender.c > cc -std plrender.o -L. -lplplot -o plrender -lX11 -lm > ld: > Unresolved: > plD_dispatch_init_xw > plD_dispatch_init_xterm > plD_dispatch_init_tekt > plD_dispatch_init_tek4107t > plD_dispatch_init_mskermit > ... > > A plain ./configure was issued, and no dynamic libs was built. Mmm, well, there's bazillions of configure bugs, we'll be fixing them forever. If you can see how to patch up the OSF support, go ahead, but I wouldn't let this platform deter us from a release. I was futzing with the Solaris support today, we still don't support shared libs on Solaris (the original ELF system, upon which LIinux shared libs are modelled). So there's lots to do in this area, over time. |
From: Joao C. <jc...@fe...> - 2002-01-21 20:05:13
|
On Monday 21 January 2002 7:07 pm, Geoffrey Furnish wrote: > Joao Cardoso writes: > > This also happens on an OSF1 alpha. Your solution also works here (b= ut > > it is not yet cvs commited, isn't it?). > > > > But, after 'make' > > > > ... > > ar: Warning: creating libplplot.a > > ranlib libplplot.a > > > > cc -std -c -O1 -I. plrender.c > > cc -std plrender.o -L. -lplplot -o plrender -lX11 -lm > > ld: > > Unresolved: > > plD_dispatch_init_xw > > plD_dispatch_init_xterm > > plD_dispatch_init_tekt > > plD_dispatch_init_tek4107t > > plD_dispatch_init_mskermit > > ... > > > > A plain ./configure was issued, and no dynamic libs was built. > > Mmm, well, there's bazillions of configure bugs, we'll be fixing them > forever. If you can see how to patch up the OSF support, go ahead, > but I wouldn't let this platform deter us from a release. Neither I was saying so. The problem seems to be the shell again, or the make program, as no drive= rs=20 object files are included in LIBS_OBJ. The offending statment seems to be= : static_drivers_obj :=3D $(STATIC_DRIVERS:%=3D%$(O)) static_drivers_obj is empty, although STATIC_DRIVERS is not. Is any cure for this? Joao |
From: Geoffrey F. <fu...@ga...> - 2002-01-21 20:21:10
|
Joao Cardoso writes: > The problem seems to be the shell again, or the make program, as no drivers > object files are included in LIBS_OBJ. The offending statment seems to be: > > static_drivers_obj := $(STATIC_DRIVERS:%=%$(O)) > > static_drivers_obj is empty, although STATIC_DRIVERS is not. > > Is any cure for this? That's a GNU make-ism. We agreed a while back to allow GNU make features in our makefiles. I don't remember typing that in specifically, but its probably mine. Anyway, for sure, it is an example of a GNU make pattern expansion. I'm gonna guess that your make is treating the % as a literal, and finding none in the STATIC)DRIVERS macro, it simply makes no change. Hmm, no, that doesn't explain your symptom. I dunno, are you using GNU make? If so, what version? -- Geoffrey Furnish fu...@ga... |
From: Maurice L. <mj...@ga...> - 2002-01-21 21:29:10
|
Geoffrey Furnish writes: > Joao Cardoso writes: > > The problem seems to be the shell again, or the make program, as no drivers > > object files are included in LIBS_OBJ. The offending statment seems to be: > > > > static_drivers_obj := $(STATIC_DRIVERS:%=%$(O)) > > > > static_drivers_obj is empty, although STATIC_DRIVERS is not. > > > > Is any cure for this? > > That's a GNU make-ism. We agreed a while back to allow GNU make > features in our makefiles. Yup. BTW I have no problems with the new version on Alpha-OSF1, using GNU make. Also my major plplot app (gts) works fine with the latest plplot, on Linux at least. There are, however, problems on IRIX. I'll come up with some fixes shortly. -- Maurice LeBrun mj...@ga... |
From: <jca...@in...> - 2002-01-22 01:59:44
|
On Monday 21 January 2002 20:21, Geoffrey Furnish wrote: | Joao Cardoso writes: | > The problem seems to be the shell again, or the make program, as | > no drivers object files are included in LIBS_OBJ. The offending | > statment seems to be: | > | > static_drivers_obj :=3D $(STATIC_DRIVERS:%=3D%$(O)) | > | > static_drivers_obj is empty, although STATIC_DRIVERS is not. | > | > Is any cure for this? | | That's a GNU make-ism. We agreed a while back to allow GNU make | features in our makefiles. I don't remember typing that in | specifically, but its probably mine. Anyway, for sure, it is an | example of a GNU make pattern expansion. I'm gonna guess that your | make is treating the % as a literal, and finding none in the | STATIC)DRIVERS macro, it simply makes no change. Hmm, no, that | doesn't explain your symptom. | | I dunno, are you using GNU make? If so, what version? No, if using gnu make-3.74 (in my home bin dir) everything runs OK.=20 Using alpha-osf1-v4.0 make(s) (there are *tree* versions of them)=20 don't work; they are /usr/bin/posix/make, /usr/opt/ultrix/usr/bin/make, /sbin/make, /usr/bin/make (link to /usr/ccs/bin/make) /bin/make (link to /usr/ccs/bin/make) Using the make man page, I got it working using static_drivers_obj =3D $(STATIC_DRIVERS/$/.o) Gnu make accepts this construct! Can this be a solution? Joao |
From: Alan W. I. <ir...@be...> - 2002-01-22 02:15:37
|
On Tue, 22 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > No, if using gnu make-3.74 (in my home bin dir) everything runs OK. Good. That is all that is required. As I understand Geoff and Maurice's posts on this issue, we no longer accomodate our Makefiles to account for everybody's different variations of the make command. Instead, our policy (which I will state in the release notes so everybody is clear about this ) is we demand our users use Gnu make. So each of our non-Linux users will be faced with exactly your situation on OSF1, and the solution for them is to download Gnu make and install and use it. I am glad it seems to be working well on OSF1. Alan |
From: Geoffrey F. <fu...@ga...> - 2002-01-22 16:06:13
|
Yes, we should state plainly that GNU make is a requirement. Besides the stuff that is in there now, for which creative people may or may not be able to find workarounds in vendor makes of various strains, there is also the issue of future embellishments to the makefiles that I aim to do, one of these days. Requiring GNU make means, for one thing, that testing on one platform provides assurance about functionality on other platforms. One problem I see with Joao's proposed solution for that one line, is that I don't know what it means without researching, and thus I cannot possibly know with confidence that it will work on /other vendor/ make's (Sun, Data General, IRIX, HP/UX, etc). By using GNU make, we can author on Linux (or whatever each developers personal preferred platfrom is), and be confident that the makefiles will also work on other systems if they just use GNU make. I view that as a significant enablement for continued improvement to the build system. Alan W. Irwin writes: > On Tue, 22 Jan 2002, [iso-8859-1] Jo=E3o Cardoso wrote: >=20 > > No, if using gnu make-3.74 (in my home bin dir) everything runs OK= . >=20 > Good. That is all that is required. >=20 > As I understand Geoff and Maurice's posts on this issue, we no longe= r > accomodate our Makefiles to account for everybody's different variat= ions of > the make command. Instead, our policy (which I will state in the re= lease > notes so everybody is clear about this ) is we demand our users use = Gnu > make. So each of our non-Linux users will be faced with exactly your= > situation on OSF1, and the solution for them is to download Gnu make= and > install and use it. I am glad it seems to be working well on OSF1. >=20 > Alan >=20 >=20 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |