FreeBSD build

[Russell]

Hello, I've been attempting to get CodeBlocks to build on freebsd, here are my specs:
* FreeBSD 6.1 i386
* wxWidgets 2.6.3
* CB SVN rev 3207

I got as far as compiling it, but it stopped halfway, the error is:
"In file included from sqplus.h:18, from SqPlus.cpp:1: /usr/include/malloc.h:3:2: error "<malloc.h> has been replaced by <stdlib.h>"
*** Error code 1

...

Is this just a problem with the current revision or is my build messed up in some way?  :?

[mandrav]

Open that file and change "#include <malloc.h>" to "#include <cstdlib>".
And be sure to tell us if it worked or not so we can make the change in our repository...

[afb]

stdlib.h is already being included, so I think all that is needed is to avoid including the non-standard malloc.h header on the FreeBSD platform ?

Code Select Expand


#ifndef _SQ_PLUS_H_
#define _SQ_PLUS_H_

#include <stdlib.h>

#ifdef __APPLE__
  #include <malloc/malloc.h>
#elif !defined(__FREEBSD__)
  #include <malloc.h>
#endif
#include <memory.h>


Something like that, anyway. HAVE_MALLOC_H is also nice, but requires config.h first. And we might not want to introduce that in the SqPlus sources ? (and this bug should go upstream)

[Russell]

Open that file and change "#include <malloc.h>" to "#include <cstdlib>".
And be sure to tell us if it worked or not so we can make the change in our repository...

that fixed it, but I am now having trouble with this:

autorevision.h:14: error: 'encoding' was not declared in this scope
...

[afb]

autorevision.h:14: error: 'encoding' was not declared in this scope

What does your src/sdk/autorevision.h look like ?
(sounds like something went wrong, generating it)

[Russell]

Code Select Expand


/*encoding="utf-8"?>*/
#ifndef AUTOREVISION_H
#define AUTOREVISION_H


#include <wx/string.h>

#define SVN_REVISION "encoding="utf-8"?>"

#define SVN_DATE     "<entry"

namespace autorevision
{
const unsigned int svn_revision = encoding="utf-8"?>;
const wxString svnRevision(_T("encoding="utf-8"?>"));
}



#endif


I did notice that at the start of the build, it mentioned something about a locale, not entirely sure if thats what it would be.
I'm building a unicode version by the way

[afb]

In case you wondered, that looks... wrong.  :-P

SVN_REVISION is supposed to be the revision number (like "3209")
and SVN_DATE a date... (like "2006-11-13 14:10:27", for instance)

[MortenMacFly]

In case you wondered, that looks... wrong.  :-P

That's right - it's wrong. The reason is that he isn't using a recent svn (>version 1.2). This is no longer supported. I suggest you (Russell) upgrade your svn before continuing...
If that is not an option to you you could also try to downgrade the sources of autorevision (only this) to at least revision 2831.
With regards, Morten.

[afb]

We so need to overhaul these revision scripts, they're getting long in the tooth...
Requiring a certain version or locale of Subversion without telling is not very nice.

At least they should be able to politely tell you when things are going totally wrong ?

Code Select Expand

svn --version --quiet

[afb]

I did notice that at the start of the build, it mentioned something about a locale, not entirely sure if thats what it would be.

BTW; Where does "svn" live on FreeBSD ?

[thomas]

We so need to...

No need to do anything, these are old issues. It's just that we get the same issue posted again and again because the working copy is still not updated.
You get that kind of problem with the "newer old" autorevision if you are using an old client and don't have it available in PATH, so the fallback entries parsing kicks in (and fails because it is an unsupported format).
The "old old" version of autorevision would work fine in this scenario, but it would fail with a newer version.

Yiannis still needs to commit the most recent version. That one should have no such problems any more, as it has no fallback path at all any more.

[afb]

What I meant is that it is getting somewhat tedious to see the same old bugs with revision/autorevision and make dist/tarball over and over again, but I know I don't have to tell you that.

What did you think about fixing update_revision.sh / using autotools, by the way ? We should make that shell script and autorevision.cpp work the same way, in order to avoid confusion...

[MortenMacFly]

We so need to...

No need to do anything, these are old issues. [...]

Hey, another idea: Why don't we put the sources out our prefered svn version into build_tools... ?! *lol* :lol: :mrgreen: ;-)
With regards, (not to be taken seriously) Morten.

[thomas]

What did you think about fixing update_revision.sh / using autotools, by the way ? We should make that shell script and autorevision.cpp work the same way, in order to avoid confusion...

Sorry, not having a clear head yet today (never talk to me before 10...).
You mean to modify the script you wrote that copies the generated header into the release tarball? Or do you mean to add a line to configure so it aborts when it doesn't find svn?

[afb]

You mean to modify the script you wrote that copies the generated header into the release tarball? Or do you mean to add a line to configure so it aborts when it doesn't find svn?

I mean modify the build scripts so that autotools would generate both revision.m4 and src/sdk/autorevision.h from the current SVN info, either cached in a "dist" tarball or retrieved from the "svn" client ?

The Fedora Core package already patches out autorevision entirelly,
for instance (and writes out the code for src/sdk/autorevision.h itself)
I don't think that the build should require svn, if all the info is there.