From: Maurice L. <mj...@ga...> - 2002-12-26 19:44:24
|
ged$ ./configure --prefix=$HOME/tools --enable-dyndrivers --disable-cxx gives: ... checking for IceConnectionNumber in -lICE... yes checking for dynamic drivers... null pbm plmeta ps pstex tk xwin creating drivers/drivers.db configure: error: conditional "am__fastdepCXX" was never defined. Usually this means the macro was only invoked conditionally. and that's where it stops. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-12-26 22:20:34
|
On Thu, 26 Dec 2002, Maurice LeBrun wrote: > ged$ ./configure --prefix=$HOME/tools --enable-dyndrivers --disable-cxx > > gives: > > ... > checking for IceConnectionNumber in -lICE... yes > checking for dynamic drivers... null pbm plmeta ps pstex tk xwin > creating drivers/drivers.db > configure: error: conditional "am__fastdepCXX" was never defined. > Usually this means the macro was only invoked conditionally. > > and that's where it stops. I cannot confirm the problem here; ./configure --prefix=/usr/local/plplot_at --enable-dyndrivers --disable-cxx works fine here. However, I have a lot more dynamic drivers than you by default so I suspect you have a special configuration file turning some of them off. Could that file be the source of the problem? Try ./configure without it. Another thought.... I did 'make distclean' and ./bootstrap.sh before the configure. Is something from an old configure interfering with your new configure? 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 __________________________ |
From: Maurice L. <mj...@ga...> - 2002-12-27 02:12:05
|
Alan W. Irwin writes: > On Thu, 26 Dec 2002, Maurice LeBrun wrote: > > > ged$ ./configure --prefix=$HOME/tools --enable-dyndrivers --disable-cxx > > > > gives: > > > > ... > > checking for IceConnectionNumber in -lICE... yes > > checking for dynamic drivers... null pbm plmeta ps pstex tk xwin > > creating drivers/drivers.db > > configure: error: conditional "am__fastdepCXX" was never defined. > > Usually this means the macro was only invoked conditionally. > > > > and that's where it stops. > > I cannot confirm the problem here; > > ./configure --prefix=/usr/local/plplot_at --enable-dyndrivers --disable-cxx > > works fine here. However, I have a lot more dynamic drivers than you by > default so I suspect you have a special configuration file turning some of > them off. Could that file be the source of the problem? Try ./configure > without it. > > Another thought.... I did 'make distclean' and ./bootstrap.sh before the > configure. Is something from an old configure interfering with your new > configure? Nope, I removed my ~/config/cf_plplot.in and tried it from a freshly checked out tree, and it still fails at the same place. Am investigating. On another note, I need to modify the command line args used by the compiler or linker. Although I've made progress, so far I still haven't gotten a completely successful build on either: Solaris, OSF1, or IRIX. As for the first two, the build is trying to pass the "-fPIC" option to the KCC compiler which isn't supported. So I need to get rid of that, or change it to +KPIC. I'm reading through the AM info pages now, what a pain. As for IRIX, I need to pass "-64 -mips4" somehow. This at least I know I can do in principle, probably by using flags like I did before: USER_FLAGS_CXX: add these to CXXFLAGS USER_FLAGS_CC: add these to CCFLAGS and so on. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-12-27 03:38:00
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > On Thu, 26 Dec 2002, Maurice LeBrun wrote: > > > > > ged$ ./configure --prefix=$HOME/tools --enable-dyndrivers --disable-cxx > > > ... > > > configure: error: conditional "am__fastdepCXX" was never defined. > > > Usually this means the macro was only invoked conditionally. I think I've tracked this down to some lunacy being done inside the AC_PROG_CXX macro, as you might expect. Using AC_* macros inside of conditionals has bitten me on the butt before.. doesn't anyone else use alternate paths of logic in configure.ac (or .in) files? Jeez. I moved AC_PROG_CXX outside of the test, i.e. if test "$enable_cxx" = yes; then ... fi AC_PROG_CXX and now it works fine. I think the reason it wasn't seen by Alan is that it's from a relatively new change and I'm working with the latest version. I don't suppose it really matters if we check for the presence of a C++ compiler despite $enable_cxx being set to "no", except for the possibility of it being confusing to the user. But now there's so much configure output that you have to look closely to even see it anyway :/. So I'm going to leave it as-is. Those wanting to reproduce the bug should install the packages I'm using and move AC_PROG_CXX back up one line, then configure with cxx disabled. Grumble.. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-12-27 03:41:57
|
On Thu, 26 Dec 2002, Maurice LeBrun wrote: > On another note, I need to modify the command line args used by the compiler > or linker. Although I've made progress, so far I still haven't gotten a > completely successful build on either: Solaris, OSF1, or IRIX. As for the > first two, the build is trying to pass the "-fPIC" option to the KCC compiler > which isn't supported. So I need to get rid of that, or change it to +KPIC. > I'm reading through the AM info pages now, what a pain. > > As for IRIX, I need to pass "-64 -mips4" somehow. This at least I know I can > do in principle, probably by using flags like I did before: > > USER_FLAGS_CXX: add these to CXXFLAGS > USER_FLAGS_CC: add these to CCFLAGS Can you just set LDFLAGS to +KPIC and CXXFLAGS and CFLAGS to "-64 -mips4" in the environment before you configure? I believe autotools tries really hard to allow the user to override that way. Of course, this suggestion will only work if the KCC compiler only warns about the -fPIC flag rather than aborting completely if it encounters it. If this works with environment variables, then it will be easier to proceed to automating it. 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 __________________________ |
From: Maurice L. <mj...@ga...> - 2002-12-27 04:02:34
|
Alan W. Irwin writes: > On Thu, 26 Dec 2002, Maurice LeBrun wrote: > > > On another note, I need to modify the command line args used by the compiler > > or linker. Although I've made progress, so far I still haven't gotten a > > completely successful build on either: Solaris, OSF1, or IRIX. As for the > > first two, the build is trying to pass the "-fPIC" option to the KCC compiler > > which isn't supported. So I need to get rid of that, or change it to +KPIC. > > I'm reading through the AM info pages now, what a pain. > > > > As for IRIX, I need to pass "-64 -mips4" somehow. This at least I know I can > > do in principle, probably by using flags like I did before: > > > > USER_FLAGS_CXX: add these to CXXFLAGS > > USER_FLAGS_CC: add these to CCFLAGS (oops, typo, the latter should just be 1 "C") > Can you just set LDFLAGS to +KPIC and CXXFLAGS and CFLAGS to "-64 -mips4" in > the environment before you configure? Potentially, yes. However my old configure script modified CXXFLAGS and CFLAGS according to the various command line flags: --with-debug, --with-profile, --with-opt. So I used the "USER_FLAGS.." variables to only add to that as needed for the vendor compiler, architecture, etc. In other words, setting USER_FLAGS_CXX means: I trust the CXXFLAGS the configure script is giving me, just add these. We can still set CXXFLAGS directly, but then we're giving up control through the usual command-line flags. That's what much of the previous logic in sysconf.in was for. Are the --with-profile, --with-debug, etc, options even being honored any more? > I believe autotools tries really hard > to allow the user to override that way. Yeah I noticed that autotools uses AM_CXXFLAGS, etc, instead of CXXFLAGS, etc, passing the latter along unmodified. > Of course, this suggestion will > only work if the KCC compiler only warns about the -fPIC flag rather than > aborting completely if it encounters it. If this works with environment > variables, then it will be easier to proceed to automating it. I just realized I misread the build output. Indeed, KCC is only warning about the -fPIC flag, so no need to do anything about it just yet. The real problem is a lot more sinister: /bin/bash ../../libtool --mode=compile KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../libltdl +K2 -O2 -c -o plstream.lo `test -f 'plstream.cc' || echo './'`plstream.cc mkdir .libs KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../libltdl +K2 -O2 -c plstream.cc -fPIC -DPIC -o .libs/plstream.lo KCC: Option -fPIC not recognized. cc: illegal suffix of output filename make[2]: *** [plstream.lo] Error 1 Uh oh.. KCC always uses the vendor compiler as its backend. And in this case it looks like Sun cc doesn't support other than ".o" for the suffix. This could potentially be a real problem for Geoff & I. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-12-27 04:05:23
|
Maurice LeBrun writes: > Uh oh.. KCC always uses the vendor compiler as its backend. And in this case > it looks like Sun cc doesn't support other than ".o" for the suffix. This > could potentially be a real problem for Geoff & I. BTW: $ uname -a SunOS xxxxx 5.7 ... -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-12-27 04:26:14
|
Maurice LeBrun writes: > Are the --with-profile, --with-debug, etc, options even being honored any more? I guess I'll answer my own question: no. The following variables (set by their corresponding --with-<xxx> command line switch) were used to modify the build parameters in a reasonably system-independent way. with_debug debug compile with_opt optimized compile with_warn full warnings turned on (default: off) with_profile add profiling code along with checks as necessary (e.g. profiling needs static library & debugging). This stuff was all in cf/sysconf.in, which is no longer being included. Is cf/sysloc.in the *only* file under cf/ currently in use? I guess I'll put it on my list to add this functionality back in, as I do have need of it at times. Sure, one can override CFLAGS or whatever to do what you want, but then you have to remember what flags are appropriate for the system you're on, every time you do it. Much better to put it in once, then never have to think about it again. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-12-27 05:14:08
|
On Thu, 26 Dec 2002, Maurice LeBrun wrote: > Is cf/sysloc.in the *only* file under cf/ currently in use? Nothing (including sysloc.in) is currently used from the cf directory. I did copy sysloc.in from that directory to the top level, and then stripped some stuff I thought was unneeded from it. You should be able to get back what you need by doing a diff between the two to see what has been added and what has been stripped from the top level version compared to the cf version of sysloc.in. Then it should be a simple matter to add back whatever extra is needed to the top level version. However, this might not be necessary, see next paragraph. One thing that puzzles me about your recent ".lo" comments is that autotools are supposed to work fine with cc on solaris (see PLATFORMS in the autobook). So I don't see why ".lo" is bothering cc. Also, from a google search, there have been commits to the libtool tree to deal specifically with KCC. So I started wondering if there was something simple (a flag or macro) that will make KCC work smoothly. I just looked at info autoconf, and indeed there is a compiler list you can give the AC_PROG_CXX and AC_PROG_CC macros, and KCC is one of those compilers. Perhaps specifying a compiler list to those macros that includes KCC is what you should be doing. Another thing worth trying on solaris is cc rather than KCC to see whether autotools does work as claimed with pure cc. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2002-12-27 17:58:54
|
Hello Maurice: In an effort to help you out, I have been poking around in info libtool this morning. If you search for "compiler characteristics" there, the documentation clearly states that for the solaris2 platform, the position-independent code switch is -KPIC rather than the -fPIC that you are getting. So I am wondering whether some of our instructions in configure.ac, sysloc.in, etc. are confusing libtool in non-gcc situations. To gain some insight into that question I suggest it is time to try a different approach; use a simple example with unmodified/unhacked configure.ac generated by autoscan as a test case. Use the autobook "hello world" example (suitably modified if necessary so it exercises what is not working for you at the moment with plplot) to see whether everything works well for all your compilers/platforms for that simple example. After all, autotools are used by thousands of projects, and if you grep for kcc and KCC in configure, it does seem to be aware of that compiler. Thus, my working hypothesis is a simple example with autoscan-generated configure.ac is going to work on all the compilers/platforms of interest to you, and that will give you some insight in what we are doing wrong for our more complicated project. 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 __________________________ |
From: Maurice L. <mj...@ga...> - 2002-12-28 05:17:59
|
To follow up on this discussion of yesterday: - Tried autoscan. Contained some interesting info, some of which might be handy in rooting out additional non-portabilities. But most of it had to do with non-ANSI C constructs and are therefore false positives AFAIAC. Didn't help out with any of my current problems, which are: - Using autoconf's built-in support of KCC to fix the build under Solaris, and improve it elsewhere. So I added: # List of C++ compilers to look for, in order. The default (autconf 2.57) is: # g++ c++ gpp aCC CC cxx cc++ cl FCC KCC RCC xlC_r xlC AC_PROG_CXX(KCC g++ c++ gpp aCC CC cxx cc++ cl FCC RCC xlC_r xlC) to configure.ac, chopping out the previous part. Didn't do a thing that I could tell except automatically get the compiler right, which *is* nice. So I'll replace the manual check by this, but still handle options as I mentioned previously. Back to Solaris.. the KCC shared lib build is still busted, as mentioned because of this: /bin/bash ../../libtool --mode=compile KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../libltdl -g -c -o plstream.lo `test -f 'plstream.cc' || echo './'`plstream.cc mkdir .libs KCC -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../libltdl -g -c plstream.cc -fPIC -DPIC -o .libs/plstream.lo KCC: Option -fPIC not recognized. cc: illegal suffix of output filename (the -fPIC warning is harmless). So I took your advice and tried using cc instead of gcc by inserting the following line in configure.ac: AC_PROG_CC(cc cl egcs gcc) which overrides the default search order, like AC_PROG_CXX. Then the build went: ... cc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../libltdl -g -c plcont.c -KPIC -DPIC -o plcont.o mv -f plcont.o .libs/plcont.lo ... So you see, there is logic in there to build the object then move it, use it in the new location, and clean up appropriately. The question is, how can I trigger this behavior for KCC? -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-12-28 07:14:41
|
On Fri, 27 Dec 2002, Maurice LeBrun wrote: > [...]So I took your advice and tried using cc > instead of gcc by inserting the following line in configure.ac: > > AC_PROG_CC(cc cl egcs gcc) > > which overrides the default search order, like AC_PROG_CXX. > Then the build went: > > ... > cc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../libltdl -g -c plcont.c -KPIC -DPIC -o plcont.o > mv -f plcont.o .libs/plcont.lo > ... > > So you see, there is logic in there to build the object then move it, use it > in the new location, and clean up appropriately. And I notice the correct -KPIC flag is in there as well. > > The question is, how can I trigger this behavior for KCC? That is a tough one. Sorry I cannot be any help on that. My only real suggestion is to try an extremely simple example to see if the correct behaviour is triggered. If that is no go, then it is probably time to take the results of that simple example to the libtool list to get the definitive answers about KCC support. But you also might find that the simple example works fine. 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 __________________________ |