OpenBSD support thread

belenus · Post by **belenus** » Wed Aug 29, 2007 10:20 am

Removed the %destructor part since it is still "experimental" in bison 2.1 (it probably is just at the wrong place within the file, like some other stuff) and found the next unclean programming part... *sigh*

first (a bit hackish but works for now):

Code: Select all

--- src/tools/values/vParser.ypp.orig   Wed Aug 22 11:16:59 2007
+++ src/tools/values/vParser.ypp        Wed Aug 29 12:33:17 2007
@@ -18,6 +18,8 @@
        #include "values/vParser.h"
        #include "tString.h"

+       int yyparse(void);
+
        int yylex(void);
        void yyerror(char const *s);

@@ -34,9 +36,9 @@
        Type::arglist *arglist;
 }

-%destructor {
-       delete $$;
-} expr function tSTRING tID
+//%destructor {
+//     delete $$;
+//} expr function tSTRING tID

 %type  <expr>  expr function;
 %type  <arglist>       arglist;

second, added ifdef because I have no idea how to do this NAN stuff otherwise...

Code: Select all

--- src/tools/values/veComparison.cpp.orig  Wed Aug 22 11:16:58 2007
+++ src/tools/values/veComparison.cpp       Wed Aug 29 11:15:34 2007
@@ -58,8 +58,10 @@
         else
             if (*m_lvalue > *m_rvalue)
                 return 1;
+#ifdef WIN32
     // cast required for windows
     return (REAL)NAN;
+#endif
 }

 Base *Compare::copy(void) const {

belenus · Post by **belenus** » Wed Aug 29, 2007 11:38 am

New error:

Code: Select all

c++  -O2 -pipe   -o armagetronad_main  armagetronad_main-gFloor.o armagetronad_main-cCockpit.o armagetronad_main-cMap.o libtron.a libenginecore.a libengine.a libnetwork.a libui.a librender.a libtools.a librubywrap.a thirdparty/mathexpr/libmathexpr.a  -L/usr/local/lib -lruby -L/usr/local/lib -lxml2 -lz -L/usr/local/lib -liconv -lm
librubywrap.a(librubywrap_a-armagetronad_wrap.o)(.text+0x4f5): In function `SWIG_PackVoidPtr':
: warning: strcpy() is almost always misused, please use strlcpy()
librubywrap.a(librubywrap_a-armagetronad_wrap.o)(.text+0x99c): In function `SWIG_Ruby_define_class':
: warning: sprintf() is often misused, please use snprintf()
/usr/local/lib/libruby.so.1.85: warning: strcat() is almost always misused, please use strlcat()
gmake[3]: Leaving directory `/usr/source/ports/games/armagetronad/server/w-armagetronad-dedicated-0.2.8.2.1p2/armagetronad-0.2.8.2.1/src'
gmake[2]: Leaving directory `/usr/source/ports/games/armagetronad/server/w-armagetronad-dedicated-0.2.8.2.1p2/armagetronad-0.2.8.2.1/src'
Making all in resource
gmake[2]: Entering directory `/usr/source/ports/games/armagetronad/server/w-armagetronad-dedicated-0.2.8.2.1p2/armagetronad-0.2.8.2.1/resource'
Traceback (most recent call last):
  File "../batch/make/sortresources.py", line 247, in <module>
    scanDir(sourceDirectory, destinationDirectory, function)
  File "../batch/make/sortresources.py", line 124, in scanDir
    os.path.walk(sourceDir, visitor, visitor )
  File "/usr/local/lib/python2.5/posixpath.py", line 298, in walk
    walk(name, func, arg)
  File "/usr/local/lib/python2.5/posixpath.py", line 298, in walk
    walk(name, func, arg)
  File "/usr/local/lib/python2.5/posixpath.py", line 290, in walk
    func(arg, top, names)
  File "../batch/make/sortresources.py", line 120, in visitor
    newPath = getCanonicalPath(path)
  File "../batch/make/sortresources.py", line 111, in getCanonicalPath
    parseResource(path, data)
  File "../batch/make/sortresources.py", line 82, in parseResource
    parser = sax.make_parser()
  File "/usr/local/lib/python2.5/xml/sax/__init__.py", line 93, in make_parser
    raise SAXReaderNotAvailable("No parsers found", None)
xml.sax._exceptions.SAXReaderNotAvailable: No parsers found
gmake[2]: *** [included] Error 1
gmake[2]: Leaving directory `/usr/source/ports/games/armagetronad/server/w-armagetronad-dedicated-0.2.8.2.1p2/armagetronad-0.2.8.2.1/resource'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/source/ports/games/armagetronad/server/w-armagetronad-dedicated-0.2.8.2.1p2/armagetronad-0.2.8.2.1'
gmake: *** [all] Error 2
*** Error code 2

Looks like some python stuff...

belenus · Post by **belenus** » Wed Aug 29, 2007 12:04 pm

python-expat package was missing, looks like it builds fine now...

...any help with that bison thingy would be appreciated tho...

...also testing if that "isnan" replacement for "NAN" works with Linux/Win/Mac... and confirmation that the "#ifdef WIN32" patch for NAN is ok.

belenus · Post by **belenus** » Wed Sep 12, 2007 11:37 am

*bump*

someone please have a look at the patches I posted and test if they also work for Linux/Mac/Windows

Luke-Jr · Post by **Luke-Jr** » Wed Sep 12, 2007 9:30 pm

belenus wrote:Removed the %destructor part since it is still "experimental" in bison 2.1 (it probably is just at the wrong place within the file, like some other stuff) and found the next unclean programming part... *sigh*

Yay for memory leaks? I think %destructor is kinda mandatory for C++...

Luke-Jr · Post by **Luke-Jr** » Wed Sep 12, 2007 9:32 pm

Lucifer wrote:Umm, I believe the bison-dependent code is currently scheduled to be removed. You could help by removing the .ypp file from the build and see if it all links, and if not, comment out the lines that need it. Could take awhile, that's why no one has done it.

Then you're back to XML-syntax-only for vValues.

Lucifer wrote:An alternative that might actually be less work could be adapting the .ypp file to work with byacc, or your version of bison.

I don't think byacc has C++ support at all.

belenus · Post by **belenus** » Thu Sep 13, 2007 2:49 pm

I was more or less thinking about the other patches (about NAN and the includes)... especially since I mentioned that the bison thing is a bit hackish...

Luke-Jr · Post by **Luke-Jr** » Fri Sep 14, 2007 8:25 pm

belenus wrote:I was more or less thinking about the other patches (about NAN and the includes)... especially since I mentioned that the bison thing is a bit hackish...

The only problem AFAIK with the "bison thing" is that it requires a BISON capable of working with C++ code (originally it was just meant for C) and doesn't support everything vValue can/does yet-- in particular, I think inline XML is neccessary.