bugGNU Octave - Bugs: bug #34725, Something regarding Lex causes...

 
 

bug #34725: Something regarding Lex causes build failure on OpenBSD

Submitter:  Edd Barrett <vext01>
Submitted:  Wed 02 Nov 2011 10:22:55 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.4.3 Operating System:  * BSD
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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.

Edd Barrett <vext01>
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...

Edd Barrett <vext01>
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.

Rik <rik5>
Group administrator
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

Edd Barrett <vext01>
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.

John W. Eaton <jwe>
Group administrator
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...

Edd Barrett <vext01>
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:


# echo $LD_LIBRARY_PATH
/usr/ports/pobj/octave-3.4.3/octave-3.4.3/libcruft/.libs:/usr/ports/pobj/octave-3.4.3/octave-3.4.3/liboctave/.libs:/usr/ports/pobj/octave-3.4.3/octave-3.4.3/src/.libs
# pwd
/usr/ports/pobj/octave-3.4.3/octave-3.4.3/src/.libs
# gdb ./octave
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd5.0"...
(no debugging symbols found)

(gdb) run
Starting program: /usr/ports/pobj/octave-3.4.3/octave-3.4.3/src/.libs/octave
^C
Program received signal SIGINT, Interrupt.
[Switching to process 32210, thread 0x87bef400]
0x015b1c9b in dlamc1_ () from /usr/local/lib/liblapack.so.6.0
(gdb) bt
#0  0x015b1c9b in dlamc1_ () from /usr/local/lib/liblapack.so.6.0
#1  0x015b142d in dlamc2_ () from /usr/local/lib/liblapack.so.6.0
#2  0x015b1db2 in dlamch_ () from /usr/local/lib/liblapack.so.6.0
#3  0x063c8da1 in d1mach_ ()
   from /usr/ports/pobj/octave-3.4.3/octave-3.4.3/libcruft/.libs/libcruft.so.0.0
#4  0x067a0a3d in get_float_format ()
   from /usr/ports/pobj/octave-3.4.3/octave-3.4.3/liboctave/.libs/liboctave.so.0.0
#5  0x067a0aff in oct_mach_info::oct_mach_info ()
   from /usr/ports/pobj/octave-3.4.3/octave-3.4.3/liboctave/.libs/liboctave.so.0.0
#6  0x067a0b5e in oct_mach_info::instance_ok ()
   from /usr/ports/pobj/octave-3.4.3/octave-3.4.3/liboctave/.libs/liboctave.so.0.0
#7  0x067a0c27 in oct_mach_info::native_float_format ()
   from /usr/ports/pobj/octave-3.4.3/octave-3.4.3/liboctave/.libs/liboctave.so.0.0
#8  0x06789ee7 in octave_ieee_init ()
   from /usr/ports/pobj/octave-3.4.3/octave-3.4.3/liboctave/.libs/liboctave.so.0.0
#9  0x090b6ed5 in octave_main ()
   from /usr/ports/pobj/octave-3.4.3/octave-3.4.3/src/.libs/liboctinterp.so.0.0
#10 0x1c00092a in main ()


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.

Edd Barrett <vext01>
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.

John W. Eaton <jwe>
Group administrator
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:


__powisf2
__powidf2
std::basic_istream<char,std::char_traits<char> >::seekg(long, std::_Ios_Seekdir)
std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::seekoff(long, std::_Ios_Seekdir, std::_Ios_Openmode)


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.

John W. Eaton <jwe>
Group administrator
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.

Edd Barrett <vext01>
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.

John W. Eaton <jwe>
Group administrator
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.

Edd Barrett <vext01>
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


octave$(EXEEXT)


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.

John W. Eaton <jwe>
Group administrator
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:

     -r      An alias for -E, for compatibility with GNU sed.


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)

Edd Barrett <vext01>
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.

John W. Eaton <jwe>
Group administrator
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:


s/\.\(cc\|yy\|ll\)$/.df/


I think you can get around this by modifying the expression to be


s/\.(cc|yy|ll)$/.df/


and calling sed with -E.

I'm not sure what the best fix is for this so that it will work on all systems.

John W. Eaton <jwe>
Group administrator
Wed 02 Nov 2011 02:26:13 PM UTC, comment #4: 

Hi John,

Looks like you are correct about .df files:


% pwd
/usr/ports/pobj/octave-3.4.3/octave-3.4.3
% find . -name '*.df*'
%                          <- (nothing!)


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:

export PKG_PATH=ftp://ftp.fr.openbsd.org/pub/OpenBSD/4.9/packages/amd64/


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.

Edd Barrett <vext01>
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


// DO NOT EDIT!  Generated automatically by mkdefs.
 XDEFUN_FILE_NAME ("src/data.cc")
 XDEFUN_INTERNAL (all, args, , "-*- texinfo -*-\n@deftypefn  {Built-in Function} {} all (@var{x})\n@deftypefnx {Built-in Function} {} all (@var{x}, @var{dim})\nFor a vector argument, return true (logical 1) if all elements of the vector\nare nonzero.\n\nFor a matrix argument, return a row vector of logical ones and\nzeros with each element indicating whether all of the elements of the\ncorresponding column of the matrix are nonzero.  For example:\n\n@example\n@group\nall ([2, 3; 1, 0]))\n     @result{} [ 1, 0 ]\n@end group\n@end example\n\nIf the optional argument @var{dim} is supplied, work along dimension\n@var{dim}.\n@seealso{any}\n@end deftypefn")


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?


John W. Eaton <jwe>
Group administrator
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):


...
static void gripe_matlab_incompatible_operator (const std::string& op);
static void display_token (int tok);
static void lexer_debug (const char *pattern, const char *text);

%}

D       [0-9]
S       [ \t]
NL      ((\n)|(\r)|(\r\n))
SNL     ({S}|{NL})
EL      (\.\.\.)
BS      (\\)
CONT    ({EL}|{BS})
Im      [iIjJ]
CCHAR   [#%]
COMMENT ({CCHAR}.*{NL})
SNLCMT  ({SNL}|{COMMENT})
NOT     ((\~)|(\!))
POW     ((\*\*)|(\^))
EPOW    (\.{POW})
IDENT   ([_$a-zA-Z][_$a-zA-Z0-9]*)
EXPON   ([DdEe][+-]?{D}+)
NUMBER  (({D}+\.?{D}*{EXPON}?)|(\.{D}+{EXPON}?)|(0[xX][0-9a-fA-F]+))
%%

%{
// Make script and function files start with a bogus token. This makes
// the parser go down a special path.
%}

<SCRIPT_FILE_BEGIN>. {
    LEXER_DEBUG ("<SCRIPT_FILE_BEGIN>.");

    BEGIN (INITIAL);
    xunput (yytext[0], yytext);
...


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)

Edd Barrett <vext01>
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.

John W. Eaton <jwe>
Group administrator
Wed 02 Nov 2011 10:22:55 AM UTC, original submission:  

Hi,

After working around bug #34663, I hit the following build error:


libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I/usr/X11R6/include -I../libgnu
-I../libgnu -I../libcruft/misc -I../liboctave -I../liboctave -I. -I. -I/usr/local/include -I/usr/X11R6
/include -O2 -pipe -DHAVE_CONFIG_H -I/usr/local/include -I/usr/X11R6/include/freetype2 -I/usr/X11R6/in
clude -I/usr/X11R6/include -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings
 -Wcast-align -Wcast-qual -O2 -pipe -pthread -O2 -pipe -MT TEMPLATE-INST/liboctinterp_la-Array-tc.lo -
MD -MP -MF TEMPLATE-INST/.deps/liboctinterp_la-Array-tc.Tpo -c TEMPLATE-INST/Array-tc.cc  -fPIC -DPIC
-o TEMPLATE-INST/.libs/liboctinterp_la-Array-tc.o
mv -f TEMPLATE-INST/.deps/liboctinterp_la-Array-tc.Tpo TEMPLATE-INST/.deps/liboctinterp_la-Array-tc.Pl
o
/bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I. -I..  -I/usr/local/include -I/u
sr/X11R6/include -I../libgnu -I../libgnu -I../libcruft/misc -I../liboctave -I../liboctave -I. -I.  -I/
usr/local/include -I/usr/X11R6/include -O2 -pipe  -DHAVE_CONFIG_H -I/usr/local/include -I/usr/X11R6/in
clude/freetype2 -I/usr/X11R6/include -I/usr/X11R6/include -Wall -W -Wshadow -Wold-style-cast -Wformat
-Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -O2 -pipe -pthread -O2 -pipe -MT liboctinterp
_la-builtins.lo -MD -MP -MF .deps/liboctinterp_la-builtins.Tpo -c -o liboctinterp_la-builtins.lo `test
 -f 'builtins.cc' || echo './'`builtins.cc
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I/usr/X11R6/include -I../libgnu
-I../libgnu -I../libcruft/misc -I../liboctave -I../liboctave -I. -I. -I/usr/local/include -I/usr/X11R6
/include -O2 -pipe -DHAVE_CONFIG_H -I/usr/local/include -I/usr/X11R6/include/freetype2 -I/usr/X11R6/in
clude -I/usr/X11R6/include -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings
 -Wcast-align -Wcast-qual -O2 -pipe -pthread -O2 -pipe -MT liboctinterp_la-builtins.lo -MD -MP -MF .de
ps/liboctinterp_la-builtins.Tpo -c builtins.cc  -fPIC -DPIC -o .libs/liboctinterp_la-builtins.o
builtins.cc:25117:2: error: #error lex.l requires flex version 2.5.4 or later
builtins.cc:25344: error: stray '\' in program
builtins.cc:25345: error: stray '\' in program
builtins.cc:25345: error: stray '\' in program
builtins.cc:25345: error: stray '\' in program
builtins.cc:25345: error: stray '\' in program
builtins.cc:25347: error: stray '\' in program
builtins.cc:25347: error: stray '\' in program
builtins.cc:25347: error: stray '\' in program
builtins.cc:25348: error: stray '\' in program
builtins.cc:25348: error: stray '\' in program
builtins.cc:25351: error: stray '#' in program
builtins.cc:25354: error: stray '\' in program
builtins.cc:25354: error: stray '\' in program
builtins.cc:25355: error: stray '\' in program
builtins.cc:25355: error: stray '\' in program
builtins.cc:25355: error: stray '\' in program
builtins.cc:25356: error: stray '\' in program
builtins.cc:25359: error: stray '\' in program
builtins.cc:25359: error: stray '\' in program
builtins.cc:25359:58: error: invalid suffix "a" on integer constant
builtins.cc:25402: error: stray '\' in program
builtins.cc:25402: error: stray '\' in program
builtins.cc:25416: error: stray '\' in program
builtins.cc:25416:18: warning: missing terminating " character
builtins.cc:25416: error: missing terminating " character
builtins.cc:25427: error: stray '#' in program
builtins.cc:25427: error: stray '\' in program
builtins.cc:25427: error: stray '\' in program
builtins.cc:25427: error: stray '\' in program
builtins.cc:25427: error: stray '\' in program
builtins.cc:25427: error: stray '\' in program
builtins.cc:25427: error: stray '\' in program
builtins.cc:25427:32: warning: missing terminating " character
builtins.cc:25427: error: missing terminating " character
builtins.cc:25452: error: stray '\' in program
builtins.cc:25478: error: stray '\' in program
builtins.cc:25506: error: stray '\' in program
builtins.cc:25629: error: stray '\' in program
builtins.cc:25656: error: stray '\' in program
builtins.cc:25685: error: stray '\' in program
builtins.cc:25685: error: stray '\' in program
builtins.cc:25685: error: stray '\' in program
builtins.cc:25685: error: stray '\' in program
builtins.cc:25685: error: stray '\' in program
builtins.cc:25685:16: warning: missing terminating ' character
builtins.cc:25685: error: missing terminating ' character
builtins.cc:25755: error: stray '@' in program
builtins.cc:25756: error: stray '@' in program
builtins.cc:25773: error: stray '\' in program
builtins.cc:25774: error: stray '\' in program
builtins.cc:25862: error: stray '\' in program
builtins.cc:25862:2: warning: missing terminating " character
builtins.cc:25862: error: missing terminating " character
builtins.cc:25895: error: stray '\' in program
builtins.cc:26023: error: stray '\' in program
builtins.cc:52: error: expected initializer before '.' token
gmake[3]: *** [liboctinterp_la-builtins.lo] Error 1


Notice this line:

builtins.cc:25117:2: error: #error lex.l requires flex version 2.5.4 or later


The default OpenBSD lexer is:

% flex --version
flex version 2.5.4


And I have also tried:

% gflex --version
gflex 2.5.35


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

Edd Barrett <vext01>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #24278:  oct-sed.diff added by vext01 (340B - application/octet-stream)
file #24274:  builtins.cc added by vext01 (2MiB - application/octet-stream - builtins.cc as generated by mkbuiltins on OpenBSD)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by vext01 (Submitted the item)
  • -email is unavailable- added by vext01 (me)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-21 rik5 Open/ClosedOpen Closed
    2011-11-02 vext01 Attached File- Added oct-sed.diff, #24278
    2011-11-02 vext01 Attached File- Added builtins.cc, #24274
    2011-11-02 vext01 Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code