Hi, 'unset CONFIG_SITE' does work. The build is successful and make check passes. Both hwloc and qthread only contain a lib directory. (gmp now too).
The CONFIG_SITE script was provided by the package site-config. Version 0.2-3.1.1 is what's installed. The README for the package does say the script will automatically switch between lib and lib64 for libdir; this behavior was what was intended. There's no other packages that depend on this, so I'm not sure why or when the SuSE package manager selected and installed it. Maybe it's part of the base package selections for development? The variable is set from the script /etc/profile.d/site.sh. It gets run by /etc/profile, which runs all *.sh scripts in the profile.d directory. This file is also installed by the site-config package. This is the best solution. Creating the link was a hack to get around the problem, and didn't attack the underlying problem. Thanks for the help; I know very little about the innards of the autoconf tools and how they work and am happy in my ignorance. Cheers, Greg PS - Sorry about not getting the mailing list on the CC: list; I thought I made sure it was this morning. > On April 16, 2015 at 12:19 PM Michael Ferguson <[email protected]> wrote: > > > Hi - > > Could you reply this to chapel-bugs so that it ends up in the archive? > > I'll fix the third-party/re2/README issue (that file moved to the > chpldocs available here: > http://chapel.cray.com/docs/latest/modules/standard/Regexp.html ) > > It would be possible to make a link at the end of hwloc/qthreads/gmp > builds... but I think that the most obvious solution would be to > *unset* CONFIG_SITE before building Chapel - e.g. > > bash$ unset CONFIG_SITE > > Does doing that solve the problem for you? Is there a reason > you would prefer the Makefiles be adjusted to make a link? > > Also, maybe the setting for CONFIG_SITE is based on a package installation. > Could you check which package provides > /usr/share/site/x86_64-unknown-linux-gnu > > and also figure out which shell setup file (e.g. .bashrc or something > in /etc) is setting CONFIG_SITE? I'm trying to understand how specific > this problem is to your installation. > > Answering your question about tests - the tests are not distributed > with the release but you can get them from a git checkout. You could > try https://github.com/chapel-lang/chapel/tree/master/test/regexp/ > and > https://github.com/chapel-lang/chapel/tree/master/test/modules/standard/gmp > > see > https://github.com/chapel-lang/chapel/blob/master/doc/developer/bestPractic > es/TestSystem.txt > for more info on the testing system - basically if you get those > test directories you'd run start_test and supply the path. > > Thanks, > > -michael > > On 4/16/15, 10:03 AM, "Greg Kreider" <[email protected]> wrote: > > > > >Hi, > > > >Yes, CONFIG_SITE is set, and the file it points to, > >/usr/share/site/x86_64-unknown-linux-gnu, does indeed define > > libdir='${exec_prefix}/lib64' > >if it finds a 64 bit system. > > > >I don't know how this got set up, or why it would be different from > >your version. > > > > > >Good news, the 'make check' problem can be fixed too. If after the > >build you go into the hwloc and qthread install directories (so > >third-party/[hwloc|qthread]/install/linux64-gnu-native[-flat]) and do > > ln -s lib64 lib > >then it works. (Also random programs from examples/primers and /programs > >work.) > > > >Maybe if the link were made at the end of the hwloc build it would > >also mean the edit to the qthread configure wasn't necessary? Where > >in the hwloc/Makefile and qthread/Makefile would that go? > > > > > >By the way, is there a test case for the re2 and gmp libraries? re2 > >creates just a lib in its install directory, but gmp makes a lib64. > >llvm also generates a lib. I'd just like to check these are working. > > > >(And as a side note, there's references in README.chplenv and > >third-party/re2/README to a file called doc/technotes/README.regexp > >that doesn't exist.) > > > >Cheers, > > > >Greg > > > > > >> On April 16, 2015 at 8:46 AM Michael Ferguson <[email protected]> > >>wrote: > >> > >> > >> Hi - > >> > >> Hmm.. I still have not been able to reproduce the problem. My opensuse > >> install also has /lib and /lib64. That lib64 is being used in a local > >> install (e.g. to third-party/hwloc/install/...) however seems to be > >> specific to your system. > >> > >> Both hwloc and qthreads are using autoconf, and I see that with > >> autoconf it is possible to override the libdir, described here: > >> > >>https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Site > >>-D > >> efaults.html > >> > >> Does your environment set CONFIG_SITE? > >> > >> You could also try modifying third-party/{qthread,hwloc}/Makefile > >> to pass a --libdir= to the configure call. > >> > >> -michael > >> > >> On 4/15/15, 9:13 PM, "Greg Kreider" <[email protected]> wrote: > >> > >> > > >> >Hi, > >> > > >> >Aha! Well, a bit. Thinking this was a problem with the qthread > >> >configuration > >> >not being > >> >able to find the hwloc library, but: > >> > - the --with-hwloc argument to the qthread configuration call is > >> > correct (the right path) > >> > - there is a file in hwloc with the function that was missing > >> > (third-party/hwloc/install/linux64-gnu-native/lib64/libhwloc.a) > >> >Searching the configure file for --with-hwloc gives at line 40459 > >> > LDFLAGS="-L$with_hwloc/lib $CPPFLAGS" > >> > > >> >SUSE for their 64-bit systems uses lib64; lib is for 32-bit libraries. > >> >Maybe they've wired this into the build tools or install program?? Is > >> >it just their distribution that does this? > >> > > >> >Anyway, changing that line to read > >> > LDFLAGS="-L$with_hwloc/lib64 $CPPFLAGS" > >> >and the build succeeds. > >> > > >> >The problem with 'make check' failing still remains. > >> >checkChplInstall-failure.log contains 1500 lines like this: > >> >> > >> > >>>>/tmp/chpl-kreider-22783.deleteme/hello2-module.tmp.o:_main.c:(.text+0x1 > >>>>91 > >> >>4c): > >> >> more undefined references to `chpl_task_yield' follow > >> >> _main.c:(.text+0x1416): undefined reference to `chpl_task_yield' > >> >> _main.c:(.text+0x15777): undefined reference to `chpl_task_yield' > >> >> _main.c:(.text+0x15cc7): undefined reference to `chpl_task_yield' > >> >> _main.c:(.text+0x182b2): undefined reference to `chpl_task_yield' > >> >> _main.c:(.text+0x59bf): undefined reference to > >> >>`chpl_task_getCallStackSize' > >> >> _main.c:(.text+0x5aca): undefined reference to `chpl_task_getMaxPar' > >> >> _main.c:(.text+0x895f): undefined reference to `chpl_task_getSerial' > >> > > >> >chpl_task_yield does exist, in > >> > > >>third-party/qthread/install/linux64-gnu-native/lib64/libqthread_chpl.a > >> > > >> >Is there another reference that needs to change to lib64? There > >>doesn't > >> >seem to be one in the make output. > >> > > >> >(Putting the full paths with lib64 for hwloc and qthread on > >> >LD_LIBRARY_PATH > >> >didn't help either. Would there be another work-around?) > >> > > >> >Greg > >> > > >> > > >> > > >> >> On April 15, 2015 at 5:09 PM Michael Ferguson <[email protected]> > >> >>wrote: > >> >> > >> >> > >> >> Hi - > >> >> > >> >> I've tried to reproduce your problem with opensuse 12.3 and 13.1 > >> >> virtual machines. Those both seem to function (build passes > >> >> make check with qthreads and hwloc). > >> >> > >> >> There is perhaps something else odd about your environment. > >> >> Do you have any guesses? (hwloc already installed? Path problems? > >> >> Some kind of permissions issue?). Alternatively, it could > >> >> be that the problem with hwloc only appears on real hardware... > >> >> > >> >> Thanks, > >> >> > >> >> -michael > >> >> > >> >> On 4/15/15, 2:51 PM, "Greg Kreider" <[email protected]> wrote: > >> >> > >> >> > > >> >> >Hi, > >> >> > > >> >> >I've just started trying to Chapel and have run into a compilation > >> >> >failure during the general build. This is for version 1.11.0 > >>running > >> >> >on a Linux box (Suse 12.3, kernel 3.7.10-1.16). > >> >> > > >> >> >The quickstart build succeeds, 'make check' passes, and several > >>other > >> >> >examples compiled and ran. > >> >> > > >> >> >Building using the environment in util/setchplenv.bash crashed while > >> >> >configuring qthread. The tail of the output from make was: > >> >> > > >> >> >third-party/qthread compile fails: > >> >> >checking for high resolution timer type... clock_gettime > >> >> >checking hwloc.h usability... yes > >> >> >checking hwloc.h presence... yes > >> >> >checking for hwloc.h... yes > >> >> >checking for library containing hwloc_topology_init... no > >> >> >configure: error: Specified topology library (hwloc) does not work. > >> >> >make[4]: *** [qthread-config] Error 1 > >> >> >make[3]: *** > >> >> >[/opt/chapel/third-party/qthread/install/linux64-gnu-native-flat] > >> >> >Error 2 > >> >> >make[2]: *** [third-party-pkgs] Error 2 > >> >> >make[1]: *** [runtime] Error 2 > >> >> > > >> >> > > >> >> >Following the notes in the README's, setting CHPL_HWLOC=none allowed > >> >> >the build to complete from this point. (Also, setting this between > >> >> >'source util/setchplenv.bash' and 'make' works.) But 'make check' > >> >> >generates many pages of loader error messages in the log, all > >>undefined > >> >> >references to 'chpl_sync_[un]lock', 'chpl_task_yield', and many many > >> >> >others. This also happens when compiling the hello_world.chpl > >>program > >> >> >from the command line. > >> >> > > >> >> >hwloc does seem to be working. hwloc-info, lstopo, and > >> >>lstopo-no-graphics > >> >> >don't crash at least. > >> >> > > >> >> >There is a bug in hwloc-gather-topology. Line 15 reads > >> >> > lstopo="$bindir/lstopo/lstopo-no-graphics" > >> >> >This should be > >> >> > lstopo="$bindir/lstopo-no-graphics" > >> >> >ie. there's no lstopo sub-directory in bindir. > >> >> >The file seems to be generated from > >> >>tests/linux/hwloc-gather-topology.in, > >> >> >which has > >> >> > # this will be changed into $bindir/lstopo during make install > >> >> > lstopo="$HWLOC_top_builddir/utils/lstopo/lstopo-no-graphics" > >> >> >It looks like utils/lstopo needs to be replaced, not just utils. > >> >> > > >> >> >But, fixing this by hand and re-starting the make does not work; it > >> >>gives > >> >> >the same error as above. I couldn't figure out from the qthread > >> >>configure > >> >> >script what it was trying to do, to duplicate the problem by hand. > >> >> > > >> >> > > >> >> >A custom setup script that leaves CHPL_HWLOC=none and > >>CHPL_TASKS=fifo, > >> >> >but does set GMP, re2, and LLVM, does compile and 'make check' > >>passes. > >> >> > > >> >> >Greg K. > >> >> > > >> >> > >> > >>>>>---------------------------------------------------------------------- > >>>>>-- > >> >>>-- > >> >> >---- > >> >> >BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > >> >> >Develop your own process in accordance with the BPMN 2 standard > >> >> >Learn Process modeling best practices with Bonita BPM through live > >> >> >exercises > >> >> >http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > >> >> >event?utm_ > >> >> > >>>source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > >> >> >_______________________________________________ > >> >> >Chapel-bugs mailing list > >> >> >[email protected] > >> >> >https://lists.sourceforge.net/lists/listinfo/chapel-bugs > >> >> > >> > ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Chapel-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-bugs
