Mon 06 Dec 2010 06:19:51 PM UTC, comment #27:
No response to request for additional information in over a month. I am closing this bug, but can re-open it if more tests or more data is available.
|
Fri 22 Oct 2010 05:01:50 PM UTC, comment #26:
Did you ever determine where the crash is happening?
|
Thu 09 Sep 2010 02:17:39 PM UTC, comment #25:
Whoops, I meant to say more:
I will install some libraries, but (for example), it is not finding arpack though I know libarpack.so is in /usr/local/lib.
Also, thanks for the help and patience! I hope that this helps the build process for octave on other machines (not that FreeBSD is all that obscure...)
Let me know if there is anything else you would like me try. I have never attached gdb to a core dump, but I could try it tonight.
|
Thu 09 Sep 2010 02:14:18 PM UTC, comment #24:
I ran with:
LDFLAGS='-L/usr/local/lib' ./configure 1>confout 2>conferr && gmake
Now I get as far as building run-octave, but it segfaults (I verified this outside of gmake). Attached are confout and conferr. Tonight I might try to install some of the supplementary libraries
../../run-octave -f -q -H -p . --eval "geometryimages ('voronoi', 'txt');"
gmake[3]: *** [voronoi.txt] Segmentation fault: 11 (core dumped)
gmake[3]: Leaving directory `/usr/home/wsprague/SOURCES/octave/doc/interpreter'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/home/wsprague/SOURCES/octave/doc'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/wsprague/SOURCES/octave'
gmake: *** [all] Error 2
(file #21424, file #21425)
|
Thu 09 Sep 2010 02:54:01 AM UTC, comment #23:
Octave doesn't use any header files for BLAS and LAPACK, so you don't need to change CPPFLAGS for this.
In which directory are the libraries installed?
Try
LDFLAGS=/dir/that/contains/blas/and/lapack ./configure
What happens then?
|
Thu 09 Sep 2010 02:10:46 AM UTC, comment #22:
WHen I do a plain sh autogen.sh && ./configure this is what I get:
configure: error: You are required to have BLAS and LAPACK libraries
I do, in fact, have those libraries, hence all the business with -I etc
|
Wed 08 Sep 2010 04:30:12 PM UTC, comment #21:
You really shouldn't have to add libgnu in CPPFLAGS or LDFLAGS as that is already done for you.
Likewise, I would not expect that you should have to use YACC=bison as Octave's configure script should only be using bison, since that is required. If it is doing something else, then
Can we attack one problem at a time?
How about doing a fresh build using the current sources after a clean checkout and simply using
./configure
make
and then let's fix one problem at a time.
Maybe we should also move this to the help or perhaps the maintainers list?
|
Wed 08 Sep 2010 03:02:15 PM UTC, comment #20:
I'm no expert, but it looks to me like the wrong getopt.h is being loaded.
/home/wsprague/SOURCES/octave/libgnu/getopt.h:196: error: redefinition of 'struct option'
/usr/include/getopt.h:53: error: previous definition of 'struct option'
Have you tried to place octave's version ahead of your system's getopt.h?
CPPFLAGS="-I$HOME/SOURCES/octave/libgnu -I/usr/local/include -I/usr/include"
Ben
|
Wed 08 Sep 2010 07:16:29 AM UTC, comment #19:
Fixed the last impasse by modifying YFLAGS with the following:
LDFLAGS="-L/usr/local/lib -L/usr/lib -L$HOME/SOURCES/octave/libgnu" CPPFLAGS="-I/usr/local/include -I/usr/include -I$HOME/SOURCES/octave/libgnu" YACC='bison' YFLAGS=' -v ' ./configure --prefix=/opt/octave-tip
Still not successfully building, now I error out when trying to build "scripts" directory, with an error in libgnu (either strings or getopt). See below
If anyone has any ideas, send them my way ... thanks!
gmake[2]: Leaving directory `/usr/home/wsprague/SOURCES/octave/src'
Making all in scripts
gmake[2]: Entering directory `/usr/home/wsprague/SOURCES/octave/scripts'
depbase=`echo gethelp.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I/usr/include -I/home/wsprague/SOURCES/octave/libg nu -g -O2 -DHAVE_CONFIG_H -mieee-fp -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include - I/usr/local/include -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2 -D_THREAD_SAFE -pthread -g -O2 -MT get help.o -MD -MP -MF $depbase.Tpo -c -o gethelp.o gethelp.cc &&\
mv -f $depbase.Tpo $depbase.Po
In file included from /home/wsprague/SOURCES/octave/libgnu/sys/select.h:58,
from /usr/include/sys/time.h:319,
from /home/wsprague/SOURCES/octave/libgnu/sys/time.h:40,
from /home/wsprague/SOURCES/octave/libgnu/sys/select.h:51,
from /usr/include/sys/types.h:314,
from /home/wsprague/SOURCES/octave/libgnu/stdio.h:48,
from /usr/include/c++/4.2/cstdio:53,
from gethelp.cc:27:
/home/wsprague/SOURCES/octave/libgnu/string.h:452: error: expected ',' or '...' before '__dest'
/home/wsprague/SOURCES/octave/libgnu/string.h:452: error: nonnull argument with out-of-range operand number (ar gument 1, operand 2)
In file included from /home/wsprague/SOURCES/octave/libgnu/unistd.h:100,
from /usr/include/c++/4.2/bits/gthr-default.h:44,
from /usr/include/c++/4.2/bits/gthr.h:114,
from /usr/include/c++/4.2/bits/c++io.h:43,
from /usr/include/c++/4.2/iosfwd:46,
from /usr/include/c++/4.2/ios:43,
from /usr/include/c++/4.2/ostream:45,
from /usr/include/c++/4.2/iostream:45,
from gethelp.cc:29:
/home/wsprague/SOURCES/octave/libgnu/getopt.h:196: error: redefinition of 'struct option'
/usr/include/getopt.h:53: error: previous definition of 'struct option'
gmake[2]: *** [gethelp.o] Error 1
gmake[2]: Leaving directory `/usr/home/wsprague/SOURCES/octave/scripts'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/wsprague/SOURCES/octave'
gmake: *** [all] Error 2
wsprague:octave 0/2 $ ls scripts/
@ftp deprecated image mkinstalldirs set statistics
ChangeLog elfun io optimization signal strings
Makefile general linear-algebra path sparse testfun
Makefile.am geometry miscellaneous pkg specfun time
Makefile.in gethelp.cc mk-pkg-add plot special-matrix
audio help mkdoc polynomial startup
|
Wed 08 Sep 2010 01:47:01 AM UTC, comment #18:
Thanks John for the tip, it definitely helped ;)...
I forced the system to use a newer version of flex (silly BSD ports thing, I will write about it later). I get farther, but I error out with the following (I am right now rerunnig after symlinking /usr/bin/flex to the new /usr/local/bin/flex, but I don't think it will matter):
<SNIP>
gmake[3]: Leaving directory `/usr/home/wsprague/SOURCES/octave/liboctave'
gmake[2]: Leaving directory `/usr/home/wsprague/SOURCES/octave/liboctave'
Making all in src
gmake[2]: Entering directory `/usr/home/wsprague/SOURCES/octave/src'
making defaults.h from defaults.h.in
gawk -f ./genprops.awk graphics.h.in > graphics.h-t
mv graphics.h-t graphics.h
gawk -v emit_graphics_props=1 -f ./genprops.awk graphics.h.in > graphics-props.cc-t
mv graphics-props.cc-t graphics-props.cc
/bin/sh ../build-aux/ylwrap lex.ll lex.octave_.c lex.cc -- flex -I -I
/usr/local/bin/gsed < mxarray.h.in \
-e "s|%OCTAVE_IDX_TYPE%|int|" > mxarray.h-t
mv mxarray.h-t mxarray.h
making oct-conf.h from oct-conf.h.in
if test -n "perl"; then \
./mk-errno-list --perl "perl" < oct-errno.cc.in > oct-errno.cc-t; \
elif test -n "python"; then \
./mk-errno-list --python "python" < oct-errno.cc.in > oct-errno.cc-t; \
else \
/usr/local/bin/gsed '/@SYSDEP_ERRNO_LIST@/D' oct-errno.cc.in > oct-errno.cc-t; \
fi
mv oct-errno.cc-t oct-errno.cc
gperf -t -C -D -G -L C++ -Z octave_kw_hash octave.gperf > oct-gperf.h-t1
1 input keys have identical hash values, examine output carefully...
/usr/local/bin/gsed 's,lookup\[,gperf_lookup[,' < oct-gperf.h-t1 > oct-gperf.h-t
mv oct-gperf.h-t oct-gperf.h
rm -f oct-gperf.h-t1
/bin/sh ../build-aux/ylwrap oct-parse.yy y.tab.c oct-parse.cc y.tab.h oct-parse.h y.output oct-parse.output -- bison -dv
/usr/home/wsprague/SOURCES/octave/src/oct-parse.yy: conflicts: 16 shift/reduce, 1 reduce/reduce
gmake[2]: *** [oct-parse.cc] Error 1
gmake[2]: Leaving directory `/usr/home/wsprague/SOURCES/octave/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/wsprague/SOURCES/octave'
gmake: *** [all] Error 2
|
Tue 07 Sep 2010 07:27:22 PM UTC, comment #17:
The directive on line 27 of lex.ll is "%top". According to the NEWS file distributed with flex, "%top" was added in version 2.5.30 which was released April 1 2003. The current release of flex is 2.5.35, released February 26, 2008. Upgrade your version of flex and this problem will probably be fixed.
|
Tue 07 Sep 2010 04:39:59 AM UTC, comment #16:
Well, I am a lot closer to a successful build with the most recent changes, but I still error out in compilation with (and I still have to specify /usr/local/include and /usr/local/lib via environmental variables).
My configure command line:
$ LDFLAGS="-L/usr/local/lib -L/usr/lib -L$HOME/SOURCES/octave/libgnu" CPPFLAGS="-I/usr/local/include -I/usr/include -I$HOME/SOURCES/octave/libgnu" YACC='bison' ./configure --prefix=/opt/octave-tip
My make command line:
$ LDFLAGS="-L/usr/local/lib -L/usr/lib -L$HOME/SOURCES/octave/libgnu" CPPFLAGS="-I/usr/local/include -I/usr/include -I$HOME/SOURCES/octave/libgnu" YACC='bison' gmake
My final error:
"/usr/home/wsprague/SOURCES/octave/src/lex.ll", line 27: unrecognized '%' directive
|
Mon 06 Sep 2010 11:28:29 AM UTC, comment #15:
This now fixed in gnulib:
2010-09-04 Bruno Haible <bruno@clisp.org>
dirfd: Fix compilation error in C++ mode on MacOS X, *BSD, IRIX.
- lib/dirent.in.h (dirfd): In C++ mode with GNULIB_NAMESPACE, turn the
macro into a function.
Reported by Jarno Rajahalme <jarno.rajahalme@nsn.com>.
|
Fri 03 Sep 2010 06:09:38 PM UTC, comment #14:
I had the same problem with ::dirfd on OSX. Got it to compile by essentially removing/commenting out the offending lines from libgnu/dirent.h. In OSX dirfd is a macro, which may be a problem for the CXX macros used on libgnu/dirent.h lines 380 and 382 (my guess).
I reported this to bug-gnulib; these lines were added recently to gnulib dirent.h and may not have yet received the testing they need(ed).
Jarno
|
Mon 16 Aug 2010 05:45:50 AM UTC, comment #13:
Unfortunately, your test code worked just fine. :(. I will keep looking in the next week and try to track the issue down. Thanks for all your help!
|
Fri 13 Aug 2010 09:20:01 PM UTC, comment #12:
This does look like a problem with gnulib. Gnulib is under rapid development so it may be worth trying to update your gnulib directory. I assume that you started your build attempts in a brand new 'hg clone' directory. There could have been leftover stuff from the automake-1.10 experience that would affect gnulib.
The error seems to suggest that dirfd is not available from the standard namespace, although configure seems to have found it.
I'm attaching a small C++ program which tries to call dirfd.
Compile it with 'g++ dirfd_test.cpp' and then run './a.out'. It should compile and run cleanly.
Assuming it does work then it is something with gnulib and it is beyond me; that is not my area of expertise.
(file #21213)
|
Thu 12 Aug 2010 12:48:41 AM UTC, comment #11:
So... Still can't build on FreeBSD. Attached is configure out and out, as well as gmake out and err. If anyone cared to take a look, I would sure appreciate it!
(file #21196, file #21197, file #21198, file #21199)
|
Wed 11 Aug 2010 04:48:18 PM UTC, comment #10:
I did get messages about ":=", though I can't access them right now.
I think the problem is elsewhere (in gnulib?), due to this:
n file included from sysdir.h:34,
from dir-ops.cc:34:
../libgnu/dirent.h:380: error: '::dirfd' has not been declared
Thanks so much for the hand-holding ^H^H^H attention!
|
Wed 11 Aug 2010 03:51:44 PM UTC, comment #9:
Octave requires GNU make. We use ':=' structures in the Makefiles. During Automake you should have gotten something like this in the logs:
|
Wed 11 Aug 2010 03:03:03 PM UTC, comment #8:
Well, one problem was that I aclocal was still 1.10 since I had not symlinked it. I am now running automake-1.11 and aclocal-1.11 per the --version switch at the command line. And I got configure to work...
... But make craps out with a lot of
"Makefile, line 1993: Need an operator"
gmake (v3.81) got farther, but stops with
In file included from sysdir.h:34,
from dir-ops.cc:34:
../libgnu/dirent.h:380: error: '::dirfd' has not been declared
gmake[3]: *** [liboctave_la-dir-ops.lo] Error 1
gmake[3]: Leaving directory `/usr/home/wsprague/SOURCES/octave/liboctave'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/usr/home/wsprague/SOURCES/octave/liboctave'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/wsprague/SOURCES/octave'
I have to go to work, so I will report later with more logs.
Once (if?) we get it to work, I am hoping I can send a patch for a "INSTALL.freebsd" documentation file. Thoughts?
Note (just a reminder) that configure has to be called with the blas and lapack library locations at the command line, which means that a lot of other libraries (sparse, etc) don't get linked. I don't think this is the root of the problem, but I wanted to mention it again.
|
Tue 10 Aug 2010 05:40:14 PM UTC, comment #7:
I think you're pretty close to solving this.
The toolchain set uses Automake to create Makefile.in files from Makefile.am and then configure to create Makefile from Makefile.in.
The jam seems to be your Automake version. From your log output, as pointed out by Judd,
configure.ac:53: version mismatch. This is Automake 1.11.1,
configure.ac:53: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:53: comes from Automake 1.10.1. You should recreate
configure.ac:53: aclocal.m4 with aclocal and run automake again.
When Automake runs in a fresh directory it either symlinks or copies certain configuration files from its repository to the local directory. If you check the script bootstrap:754 you will see that Octave chooses the copy option. The critical thing to note is that this copying only happens on a virgin directory. Once you have run Automake once in a directory it no longer needs to copy over the library stuff, but only create Makefile.in.
My suspicion is that you ran automake-1.10 in the directory, discovered it was not the required version, and then ran automake-1.11. Unfortunately, at this point the directory is poisoned with 1.10 files and no amount of re-running automake-1.11 will cure it.
I've had this happen on a different autotools-based project and the simplest thing to do was to start over. I don't believe that aclocal.m4 is the only file which needs regeneration.
So, my advice is:
1) Use 'hg clone' to create a virgin source code directory.
2) Modify autogen.sh to ensure automake-1.11 is called.
3) Run autogen.sh and collect the logs just in case I'm wrong.
|
Tue 10 Aug 2010 12:31:02 PM UTC, comment #6:
I have the following line in my autogen.sh that I added.
AUTOMAKE="/opt/automake-1.11.1/bin/automake-1.11 --warnings=no-portability"
octave 2/0 $ automake --version
automake (GNU automake) 1.11.1
wsprague:octave 2/0 $ autoconf --version
autoconf (GNU Autoconf) 2.62
However, the latest FreeBSD native ports install of automake is 1.10, and I have automake-1.11 in /opt and then symlinked from /usr/local/bin
tx!
|
Tue 10 Aug 2010 06:58:22 AM UTC, comment #5:
Forkandwait: What are you autoconf and automake versions?
|
Tue 10 Aug 2010 05:13:16 AM UTC, comment #4:
Most of autogenout is the same as seen on my machine except these lines at the end are missing in the attachment:
./bootstrap: ln -fs ../gnulib/build-aux/install-sh build-aux/install-sh
./bootstrap: ln -fs ../gnulib/build-aux/missing build-aux/missing
./bootstrap: ln -fs ../gnulib/build-aux/mdate-sh build-aux/mdate-sh
./bootstrap: ln -fs ../gnulib/build-aux/depcomp build-aux/depcomp
./bootstrap: ln -fs ../gnulib/build-aux/config.guess build-aux/config.guess
./bootstrap: ln -fs ../gnulib/build-aux/config.sub build-aux/config.sub
./bootstrap: ln -fs gnulib/doc/INSTALL INSTALL
./bootstrap: done. Now you can run './configure'.
|
Tue 10 Aug 2010 05:04:34 AM UTC, comment #3:
These are the lines in your autogenerr that are not present when ./autogen.sh is run on Ubuntu 10.4:
/usr/local/share/aclocal/imlib.m4:9: warning: underquoted definition of AM_PATH_IMLIB
/usr/local/share/aclocal/imlib.m4:9: run info '(automake)Extending aclocal'
/usr/local/share/aclocal/imlib.m4:9: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
configure.ac:53: version mismatch. This is Automake 1.11.1,
configure.ac:53: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:53: comes from Automake 1.10.1. You should recreate
configure.ac:53: aclocal.m4 with aclocal and run automake again.
That warning about using definitions from automate 1.10.1 seems suspicious but I'm not sure. This is the version of automake installed on my machine:
$ automake --version
automake (GNU automake) 1.11.1
|
Tue 10 Aug 2010 04:45:00 AM UTC, comment #2:
I have attached files made by the following, in bash.
sh autogen.sh 2>autogenerr 1>autogenout
"2>" is the stderr stream
"1>" is the stdout stream
(file #21179, file #21180)
|
Tue 10 Aug 2010 03:43:42 AM UTC, comment #1:
Makefile.in is created by automake which is called from autogen.sh. If the file isn't there then something went wrong in autogen.sh, not in configure.
Post the exact command you used to invoke autogen.sh and a log of the results.
For example, for csh
'sh autogen.sh |& tee build.log'
|
Tue 10 Aug 2010 01:05:01 AM UTC, original submission:
I am unable to build tip on FreeBSD.
I have installed a new automake-1.11, I ran autogen from the source directory, then I ran configure like so (it doesn't recognize the blas and lapack libraries without help):
./configure --prefix=/opt/octave-hg/ --with-blas=/usr/local/lib/libblas.so --with-lapack=/usr/local/lib/liblapack.so
It bombs with the following
configure: creating ./config.status
config.status: error: cannot find input file: Makefile.in
Here is hg summary:
parent: 10876:53ec464300ef tip
_print_parse_opts_.m: Default pstex suffix should be '.ps'.
branch: default
commit: 2 modified, 8010 unknown
update: (current)
If anyone can help me, I will happily send copies of the voluminous output or anything else that might be useful.
Tx!
|