Tue 21 Feb 2012 07:54:07 PM UTC, comment #20:
But yes, close this bug, I saw no such problem with the release candidate -- i can always re-open the report if i have trouble.
|
Tue 21 Feb 2012 06:17:34 PM UTC, comment #19:
Trying to test your release candidate.
Sorry, which file (in lapack) is it that you have to build with -ffloat-store?
dlamc.f does not exist...
|
Mon 20 Feb 2012 08:41:00 PM UTC, comment #18:
Can this bug report be closed? It seems that the bug was localized to LAPACK rather than Octave. In any case, it would be better to reproduce this on a 3.6.1 release candidate.
|
Fri 04 Nov 2011 01:17:45 PM UTC, comment #17:
OK, the lapack port in openbsd has been patched with it's own BSD Makefile for some reason. This made it hard to turn off optimisation for a single object (an expression of the form 'target: VAR=X' is apparently a gmake extension.
A long story short, I build the whole thing with no optimisation; obviously a bad solution, but it will do for now, I will fix this later.
There is now a seg fault relating to signals, which we should discuss on #34663, as it is likely to be related to this.
Cheers
|
Thu 03 Nov 2011 06:12:23 PM UTC, comment #16:
I suspect an infinite loop in computing machine precision.
As I recall, this is an optimzer bug in GCC, but you can work around it by turning off optimization for the file that computes the machine precision.
I think it is dlamc.f.
Or, you can try adding -ffloat-store to the compiler flags for that file.
You don't want to disable optimization or use -ffloat-store for all files.
|
Thu 03 Nov 2011 06:04:57 PM UTC, comment #15:
Oh, and during the hang, the CPU usage is ever increasing.
I feel like we are so close...
|
Thu 03 Nov 2011 06:02:32 PM UTC, comment #14:
After rebuilding lapack and blas with gfortran (and informing lapack to use an internal etime), octave builds and links.
However, it now hangs. Sadly I forgot to include debug symbols:
I am running octave out of the build directory (is that OK?).
Sadly the install target fails, so I can't try it outside the build dir for now.
|
Wed 02 Nov 2011 11:40:16 PM UTC, comment #13:
OK, I think the linker error that I'm seeing is due to mixing an old version of g77 with a newer version of gcc.
Octave's configure script tries to find out what -L and -l options to use to link Fortran libraries.
From running g77, it finds a -L/usr/local/lib/... directory corresponding to the old g77. That causes the linker to find an old version of -lgcc, I think. At least I think this explains the problem with the __pow* symbols.
I'm not sure about the stream symbols.
|
Wed 02 Nov 2011 08:12:23 PM UTC, comment #12:
Can you post details about the problem you are having with building the documentation?
The formatted documentation files are also distributed with the sources, so you are not supposed to have to rebuild them. But you touched some source files, and doc strings are extracted from those, so that could force Make to rebuild the formatted documentation files.
I haven't solved the linker problem. Even with forcing the C++ compiler to be used, I still get errors about the following undefined symbols:
I have no idea why this is happening. Octave doesn't call these pow functions directly and I don't know why only those two C++ iostream functions would be undefined.
|
Wed 02 Nov 2011 07:53:40 PM UTC, comment #11:
Thanks, although will we not get the same doc problem at runtime? I would rather attempt to fix it.
About the linking bug, yep, I see it, I thought you meant compile time linking. Can you post a patch for the linker bug. Cheers.
|
Wed 02 Nov 2011 07:49:11 PM UTC, comment #10:
To avoid having to know what sed options are acceptable on various platforms, I checked in this change instead:
http://hg.savannah.gnu.org/hgweb/octave/rev/4cf7356a99d0
You can disable building the documentation if you like using the configure option --disable-docs. You'll still need makeinfo (from the Texinfo package) to format the help text for individual functions at run time.
|
Wed 02 Nov 2011 07:38:05 PM UTC, comment #9:
Hi again John,
The build has continued and crashed out on documentation, so I will raise a separate bug for this.
Oddly, I have not had any linking issue.
But as far as this particular bug is concerned, your sed fix and using -r seems to have worked! Will you be applying this patch to the octave dev branch?
Thanks for your help.
|
Wed 02 Nov 2011 05:50:11 PM UTC, comment #8:
Linking Octave failed in the end because the C compiler was used for linking. I'm seeing if using CXXLINK in the command used to link
is sufficient. I modified the generated Makefile to avoid having to run configure again.
Things have changed in the current sources so that this can't be the right fix now, and in my current sources the C++ compiler is used for the final link anyway, so I don't think any change would be needed for the current sources.
|
Wed 02 Nov 2011 05:12:47 PM UTC, comment #7:
Yes indeed, applying this change builtins.cc contains only C! \o/
-E is not available on linux, however, -r is available on OpenBSD:
Sounds about right?
I am attaching a diff, kicking off a full build now. Hopefully this will be octave-3.4.3 running on OpenBSD!
Cheers
(file #24278)
|
Wed 02 Nov 2011 04:51:55 PM UTC, comment #6:
I went with this change:
http://hg.savannah.gnu.org/hgweb/octave/rev/4cf7356a99d0
If this fixes the problem for you, I'll close this report.
|
Wed 02 Nov 2011 04:42:20 PM UTC, comment #5:
Thanks for the tip about packages.
OK, I have OpenBSD 5.0 installed and configure runs successfully with CPPFLAGS="-I/usr/X11R6/include -I/usr/local/include" LDFLAGS="-L/usr/X11R6/lib -L/usr/local/lib"
It looks like the builtins.cc problem might be caused by the following sed expression in src/find-defun-files.sh failing:
I think you can get around this by modifying the expression to be
and calling sed with -E.
I'm not sure what the best fix is for this so that it will work on all systems.
|
Wed 02 Nov 2011 02:26:13 PM UTC, comment #4:
Hi John,
Looks like you are correct about .df files:
There are no df files. I reckon this is likely to be subtle differences between our toolchains.
OK, here is how to build on OpenBSD:
You can install packages using pkg_add. Make sure you have set the environment variable PKG_PATH (usually I set this in /etc/profile), for example:
Notice the URL is sensitive to OpenBSD version and your system architecture.
Now you can add packages with `pkg_add -i <pkgname>` as root.
I think you will need:
g77
libf2c
gmake
desktop-file-utils
fftw3
lapack
blas
amd
umfpack
pcre
curl
glpk
Although some of these may be optional, this is what I am using.
Note that packages are installed in /usr/local, which is not a default include and linker path, so you will have to set the "influential environment variables" prior to running ./configure
If you need a newer flex than what is in the base distribution, then install the "flex package", the binary for this is 'gflex' similarly for gcc the binary name for this is 'egcc'.
This is the patch I am using to work around #34663:
https://raw.github.com/vext01/ports-wip/master/math/octave/patches/patch-src_sighandlers_cc
I hope this helps and thanks for your time.
|
Wed 02 Nov 2011 02:05:47 PM UTC, comment #3:
The builtins.cc file is not distributed with the Octave sources.
Look at the src/mkbuiltins script. It is a fairly simple shell script that uses sed.
But I think the problem is that your generated .df files are not correct.
The .df files are intermediate files that should contain lines like
The src/mkdefs script is another fairly small script that uses sed. It processes C++ preprocessor output.
So why is generating the .df files not working?
I have a copy of OpenBSD installed in a VM. How did you install dependencies like LAPACK+BLAS? Are there packages available for OpenBSD?
|
Wed 02 Nov 2011 01:43:44 PM UTC, comment #2:
Hi John,
Thanks for the prompt reply.
I was unaware that flex was an optional dependency and I have no need to modify octave's grammar. Given that I have not changed or removed lex.cc or lex.ll as distributed with the octave-3.4.3 tarball, this should work, right?
Put differently, the build error I have posted was generated from a freshly extracted tarball with no changes to any file related to the lexer (i have patched src/sighandlers.cc, which i believe to be unrelated).
Looking at the error message, this is builtins.cc complaining and not lex.cc. builtins.cc is autogenerated during the build (was this supposed to be supplied pre-generated too?).
If I run "make builtins.cc" manually and inspect the resulting builtins.cc, I noticed the file contains lex token definitions (This is what I mean by, can c++ compile lex tokens - I think the answer is no and something is fishy about this):
I see this with both flex 2.5.35 and 2.5.4 (assuming that adjusting LEX in src/Makefile will make a difference).
The build for this step looks like this:
% gmake builtins.cc
./DLD-FUNCTIONS/config-module.sh ..
../src/DLD-FUNCTIONS/module.mk is unchanged
./mkbuiltins bitfcns.cc data.cc debug.cc defaults.cc dirfns.cc error.cc file-io.cc graphics.cc help.cc input.cc lex.ll load-path.cc load-save.cc ls-oct-ascii.cc mappers.cc oct-hist.cc oct-parse.yy octave.cc pager.cc pr-output.cc sighandlers.cc sparse.cc strfns.cc symtab.cc syscalls.cc sysdep.cc toplev.cc utils.cc variables.cc ov-base.cc ov-bool-mat.cc ov-cell.cc ov-class.cc ov-fcn-handle.cc ov-fcn-inline.cc ov-flt-re-mat.cc ov-null-mat.cc ov-range.cc ov-re-mat.cc ov-struct.cc ov-typeinfo.cc ov-usr-fcn.cc ov.cc ov-int16.cc ov-int32.cc ov-int64.cc ov-int8.cc ov-uint16.cc ov-uint32.cc ov-uint64.cc ov-uint8.cc pt-arg-list.cc pt-binop.cc pt-eval.cc pt-mat.cc > builtins.cc-t
mv builtins.cc-t builtins.cc
I am attaching a full builtins.cc as I see it on my system.
Hopefully I have explained clearly.
Cheers
(file #24274)
|
Wed 02 Nov 2011 12:44:33 PM UTC, comment #1:
Flex 2.5.35 should work (that is much newer than 2.5.4, so yes, the #error line in lex.ll should probably be updated).
Flex can generate code that can be compiled with a C++ compiler.
If you are building using sources freshly extracted from a tarball release, then you should already have lex.cc and you should not need flex unless you need to modify lex.ll.
If you deleted the generated lex.cc file that is distributed in the Octave sources, then recreated it with the OpenBSD flex, then I think that could cause the trouble you are seeing.
Try deleting the lex.cc file and recreating it with flex 2.5.35 or using the version of the file that is distributed with Octave.
If you still have trouble, then post the command that Make is executing to generate lex.cc from lex.ll.
|
Wed 02 Nov 2011 10:22:55 AM UTC, original submission:
Hi,
After working around bug #34663, I hit the following build error:
Notice this line:
The default OpenBSD lexer is:
And I have also tried:
So the error seems wrong.
The other thing that surprises me here is that we appear to be building lexer input with g++. Is this some GNU extension that OpenBSD does not understand? Having said that I am using gmake, flex, gcc/g++; all GNU tools.
Help would be most appreciated.
See bug #34663 for a config.log.
This is OpenBSD-current on amd64.
Cheers
|