error when compiling from svn sources (25-10/2006)

[Brain Damage]

hi, since i could not find a compatible rpm for mandriva i tried to build code::blocks from the sources;

the bootstrap, & configure worked fine, but when i do run make i get this error:

./auto_revision +int +wx +t ../../.. ./../../sdk/autorevision.h
*** glibc detected *** ./auto_revision: free(): invalid next size (normal): 0x0804f2f8 ***
======= Backtrace: =========
/lib/i686/libc.so.6[0x401c0dad]
/lib/i686/libc.so.6(__libc_free+0x83)[0x401c0f33]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x400f9d91]
/usr/lib/libstdc++.so.6(_ZdaPv+0x1d)[0x400f9ded]
/usr/lib/libstdc++.so.6(_ZNSt13basic_filebufIcSt11char_traitsIcEE26_M_destroy_internal_bufferEv+0x2f)[0x4009d3af]
/usr/lib/libstdc++.so.6(_ZNSt13basic_filebufIcSt11char_traitsIcEE5closeEv+0x61)[0x400a0141]
./auto_revision[0x804a55b]
./auto_revision[0x804ae4a]
/lib/i686/libc.so.6(__libc_start_main+0xdc)[0x4017175c]
./auto_revision(__gxx_personality_v0+0x41)[0x80491d1]
======= Memory map: ========
08048000-0804c000 r-xp 00000000 03:05 599172     /home/cloud/code::blocks/trunk/src/build_tools/autorevision/auto_revision
0804c000-0804d000 rwxp 00004000 03:05 599172     /home/cloud/code::blocks/trunk/src/build_tools/autorevision/auto_revision
0804d000-0806e000 rwxp 0804d000 00:00 0          [heap]
40000000-40018000 r-xp 00000000 03:05 324624     /lib/ld-2.4.so
40018000-40019000 r-xp 00017000 03:05 324624     /lib/ld-2.4.so
40019000-4001a000 rwxp 00018000 03:05 324624     /lib/ld-2.4.so
4001a000-4001b000 rwxp 4001a000 00:00 0
40031000-40040000 r-xp 00000000 03:05 324618     /lib/i686/libpthread-2.4.so
40040000-40042000 rwxp 0000e000 03:05 324618     /lib/i686/libpthread-2.4.so
40042000-40044000 rwxp 40042000 00:00 0
40044000-40046000 r-xp 00000000 03:05 324635     /lib/libdl-2.4.so
40046000-40048000 rwxp 00001000 03:05 324635     /lib/libdl-2.4.so
40048000-40121000 r-xp 00000000 03:05 108189     /usr/lib/libstdc++.so.6.0.8
40121000-40124000 r-xp 000d9000 03:05 108189     /usr/lib/libstdc++.so.6.0.8
40124000-40126000 rwxp 000dc000 03:05 108189     /usr/lib/libstdc++.so.6.0.8
40126000-4012c000 rwxp 40126000 00:00 0
4012c000-4014f000 r-xp 00000000 03:05 324616     /lib/i686/libm-2.4.so
4014f000-40151000 rwxp 00023000 03:05 324616     /lib/i686/libm-2.4.so
40151000-4015b000 r-xp 00000000 03:05 324667     /lib/libgcc_s-4.1.1.so.1
4015b000-4015c000 rwxp 0000a000 03:05 324667     /lib/libgcc_s-4.1.1.so.1
4015c000-40283000 r-xp 00000000 03:05 324614     /lib/i686/libc-2.4.so
40283000-40284000 r-xp 00126000 03:05 324614     /lib/i686/libc-2.4.so
40284000-40286000 rwxp 00127000 03:05 324614     /lib/i686/libc-2.4.so
40286000-4028b000 rwxp 40286000 00:00 0
40300000-40321000 rwxp 40300000 00:00 0
40321000-40400000 ---p 40321000 00:00 0
bfae0000-bfaf6000 rw-p bfae0000 00:00 0          [stack]
bfffe000-bffff000 r-xp bfffe000 00:00 0

[phireis]

I got the same prob.
I'm trying on Suse 10.0.

Lipe

[aarti_pl]

same on ubuntu 6.06

Regards
Aarti_pl

[krom xp]

I have the same problem in ubuntu 6.10 with svn revision 3151, and did some debugging. The problem is because the program "autorevision.cpp" only understands English and our locale is other, so the svn messages are in other language.

A quick fix, to compile use this command:

Code

# LANG=C make

Or you can edit trunk/src/build_tools/autorevision/Makefile.am and add the LANG=C before the ./auto_revision, and then rerun bootstrap.

Or you can edit the file trunk/src/build_tools/autorevision/autorevision.cpp and find the line that says

Code

string svncmd("svn info ");

And change to look like this

Code

string svncmd("LANG=C svn info ");

Or you can wait for one patch I'm doing to use the xml output of svn.

[killerbot]

Or you can edit the file trunk/src/build_tools/autorevision/autorevision.cpp and find the line that says

Code

string svncmd("svn info ");

And change to look like this

Code

string svncmd("LANG=C svn info ");

Gonna try this today on windows and my linux box --> if ok will patch our sources like that

[EDIT] : I think the LANG=C will only work on linux, not on windows.

[krom xp]

killerbot, i forgot to mention another problem of the output of `svn info`. The dates are localized, I will put one example, in english and spanish, to see the differences:

Code

xxxx@xxxx:~/program/codeblocks/trunk$ svn info
Ruta: .
URL: svn://svn.berlios.de/codeblocks/trunk
Raíz del repositorio: svn://svn.berlios.de/codeblocks
UUID del repositorio: 98b59c6a-2706-0410-b7d6-d2fa1a1880c9
Revisión: 3151
Tipo de nodo: directorio
Agendado: normal
Autor del último cambio: pecan
Revisión del último cambio: 3151
Fecha de último cambio: 2006-10-28 06:02:25 +0800 (sáb, 28 oct 2006)

xxxx@xxxx:~/program/codeblocks/trunk$ LANG=C svn info
Path: .
URL: svn://svn.berlios.de/codeblocks/trunk
Repository Root: svn://svn.berlios.de/codeblocks
Repository UUID: 98b59c6a-2706-0410-b7d6-d2fa1a1880c9
Revision: 3151
Node Kind: directory
Schedule: normal
Last Changed Author: pecan
Last Changed Rev: 3151
Last Changed Date: 2006-10-28 06:02:25 +0800 (Sat, 28 Oct 2006)

The date is "2006-10-28 06:02:25", now lets see the xml output:

Code

xxxx@xxxx:~/program/codeblocks/trunk$ svn --xml info
<?xml version="1.0" encoding="utf-8"?>
<info>
<entry
   kind="dir"
   path="."
   revision="3151">
<url>svn://svn.berlios.de/codeblocks/trunk</url>
<repository>
<root>svn://svn.berlios.de/codeblocks</root>
<uuid>98b59c6a-2706-0410-b7d6-d2fa1a1880c9</uuid>
</repository>
<wc-info>
<schedule>normal</schedule>
</wc-info>
<commit
   revision="3151">
<author>pecan</author>
<date>2006-10-27T22:02:25.150469Z</date>
</commit>
</entry>
</info>

The date is "2006-10-27 22:02:25". I think this is the 'real' date, if you dont use the xml version the dates wont be the same between build of people with diffent timezone (unless you save also the time difference).

Tell me if is ok to make a patch to use the xml version and I'll finish it.

I forgot to say LANG=C is only for linux, is other reason to use the xml output, it can be done system independent.

[killerbot]

well, we will need the insight of Thomas, he made this tool.
He's best suited to judge on the best solution.

[thomas]

Yes, the problem is that the svn client does not offer an easy way to get anything back in a sane, standardised form. Instead, all output is in human readable, but not quite so good parseable form, and localised without any option to turn that off.
Granted, a few commands recently support xml output, but that's still inconsistently available in the latest version.

The solution pointed out by krom xp is almost the good one. Subversion listens to the LANG variable, so setenv("LANG", "en"); as it was done in early versions of the svn plugin should work. I abandoned that strategy since it might affect other programs launched from Code::Blocks in an unpredictable manner, but that should not be a problem for autorevision.

Will implement the fix in the next 15-20 minutes...

[afb]

I have the same problem in ubuntu 6.10 with svn revision 3151, and did some debugging. The problem is because the program "autorevision.cpp" only understands English and our locale is other, so the svn messages are in other language.

A quick fix, to compile use this command:

Code

# LANG=C make

Lucky thing that RPM always sets LANG=C when building packages...
One less thing to worry about, so just the "bootstrap" and "pkgconfig" left.

[killerbot]

I am now no longer to build on linux (Suse 10.1)
This is the eror message I get (and afterwards crash and backtrace) :
svn : error : cannot set LC_ALL locale
svn : error : environment variable LANG is EN
svn : error : please check that your locale name is correct

Any ideas ??

[afb]

Did you update to Subversion 1.4.0 and set your locale to english ?

I get the same warning on Mac OS X, but it still succeeds to make it.

Code

svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is EN
svn: warning: please check that your locale name is correct

src/sdk/autorevision.h:

Code

/*3157*/
#ifndef AUTOREVISION_H
#define AUTOREVISION_H


#include <wx/string.h>

#define SVN_REVISION "3157"

#define SVN_DATE     "2006-10-29 15:43:54"

namespace autorevision
{
        const unsigned int svn_revision = 3157;
        const wxString svnRevision(_T("3157"));
}



#endif

[Pecan]

I am now no longer to build on linux (Suse 10.1)
This is the eror message I get (and afterwards crash and backtrace) :
svn : error : cannot set LC_ALL locale
svn : error : environment variable LANG is EN
svn : error : please check that your locale name is correct

Any ideas ??

I solved this on my 10.3 OSX with LANG=en_US

LANG=EN did not work. Maybe it should be LANG=en

[killerbot]

my svn is 1.3.0, but I get errors instead of warnings.

should we try out the en_US as permanent fix ?? (gonna try to build with that first)


YES : that did it.

will change in svn, hopefully it doesn't break for someone else now

[afb]

my svn is 1.3.0, but I get errors instead of warnings.

I thought svn 1.4.0 was required now ?

should we try out the en_US as permanent fix ?? (gonna try to build with that first)

Or perhaps the usual LANG=C locale ?

edit: never mind, saw the Windows comment...
en_US it is, to cater for the least common denom

[thomas]

Interesting... I even considered using LANG=jwsdhadgh or LANG=none for a while, since gettext should fall back to whatever is built-in if it can't find it (which is the desired effect). :lol:
But then, LANG=EN looked a lot nicer, so I stuck with that. Interestingly, it does not produce any kind of warning under Windows

I did not choose any kind of subset such as en_US because I wasn't sure which one to take  (US citizens will probably claim that en_US is without doubt the "original thing", but UK residents will not necessarily agree that this is English at all). I don't know which one is the native one. Maybe en_US and en_UK (or en_AU) are even the same for Subversion by coincidence. But honestly, I actually don't want to bother

What we need is one format that's always the same, preferrably the one that's built into the Subversion binary, so it will run on every target PC. My proposal is that you try whatever doesn't give you errors, and we'll stick with that for now (until someone else complains).

Eventually, at some point in the future, I will rewrite autorevision to parse Subversion's xml output, which will once and for all end this sad story.
However, since most people still use 1.3 (which only supports that option for a small subset of commands) and some even 1.2 (which doesn't support it at all), this is currently probably not such a good idea.

[thomas]

my svn is 1.3.0, but I get errors instead of warnings.

I thought svn 1.4.0 was required now ?

All that matters is what a man can do, and what a man can't do.

For instance, you can:
- check out with Subversion 1.4 and have svn in PATH
- check out with Subversion 1.4 and not have svn available
- check out with Subversion 1.0, 1.1, 1.2, or 1.3 and have svn in PATH

What you cannot do is:
- check out using 1.3 and not have svn in PATH
- check out using 1.4 and have svn 1.3 in PATH
- check out using 1.3, update using 1.4, then change your mind and expect things still to work

Are you man enough to sail under a pirate's flag then? 

[afb]

Are you man enough to sail under a pirate's flag then? 

I use CVS :-P

But I guess checking out with /opt/local/bin/svn was a bad idea.
When I have to compile SVN, then I might as well go for 1.4.0...

[ddd]

Interesting... I even considered using LANG=jwsdhadgh or LANG=none for a while, since gettext should fall back to whatever is built-in if it can't find it (which is the desired effect). :lol:
But then, LANG=EN looked a lot nicer, so I stuck with that. Interestingly, it does not produce any kind of warning under Windows

I did not choose any kind of subset such as en_US because I wasn't sure which one to take  (US citizens will probably claim that en_US is without doubt the "original thing", but UK residents will not necessarily agree that this is English at all). I don't know which one is the native one. Maybe en_US and en_UK (or en_AU) are even the same for Subversion by coincidence. But honestly, I actually don't want to bother

What we need is one format that's always the same, preferrably the one that's built into the Subversion binary, so it will run on every target PC. My proposal is that you try whatever doesn't give you errors, and we'll stick with that for now (until someone else complains).

Isn't it possible to unset the variable instead? Wouldn't that produce the output that is built inside svn?
I tried both unsetting the variable and setting it to empty, and I got english text output. (I'm using Ubuntu Linux)

[Game_Ender]

Eventually, at some point in the future, I will rewrite autorevision to parse Subversion's xml output, which will once and for all end this sad story.
However, since most people still use 1.3 (which only supports that option for a small subset of commands) and some even 1.2 (which doesn't support it at all), this is currently probably not such a good idea.

The subversion developers don't recommend parsing the output of the subversion command lines tools.  That's why your job is so hard.  Have you considered using the libraries they provide instead?

[thomas]

The subversion developers don't recommend parsing the output of the subversion command lines tools.  That's why your job is so hard.  Have you considered using the libraries they provide instead?

Alas, poor Yorick! I knew him, Horatio: a fellow of infinite jest, of most excellent fancy...

That question should get you the best-computer-joke-of-the-year award

As this is the first obvious thing to try for a Subversion plugin (rather than launch an external tool that is not found / the wrong version / slow / error-prone), I certainly tried before.
The libraries they provide neither work with MinGW, nor does it seem feasible to convert them. Compiling Subversion from source is a story of its own...
The first dependency is Neon. Get back to me when you have managed to compile Neon with MinGW

[afb]

The subversion developers don't recommend parsing the output of the subversion command lines tools.

Subversion has been affected by the same disease as Yum then...
It even changes the output on purpose, to defeat screenscraping.

My sympathies to you, Thomas. Seems like an awful amount of
work just to get a single revision number in the about box... :-)

[tiwag]

why not providing a svn executable in the svn repository ?
then you always could use "svn info" and parse the revision number from there ?

[thomas]

Subversion has been affected by the same disease as Yum then...
It even changes the output on purpose, to defeat screenscraping.

My sympathies to you, Thomas. Seems like an awful amount of
work just to get a single revision number in the about box... :-)

The funny thing is that the "official correct way" to do that is to run svn in backticks from the makefile and pipe the output through sed. We'd probably do that if we were building Code::Blocks with makefiles everywhere. But even then it would be a pain, as it would have the very same issues.
So we're rather using one tool everywhere instead of two solutions for two build systems, both of which don't work reliably  :lol:

[thomas]

why not providing a svn executable in the svn repository ?
then you always could use "svn info" and parse the revision number from there ?

Distributing executables for being able to build from source is giving me the creeps...

Apart from that, we would need at least 3 executables (Windows, Linux/BSD, Mac) to cover the four most used platforms. Actually twice as many, if you account for 32/64 bits and Intel/PPC...

Also, we would still have potential issues then. If we distribute Subversion 1.3, but someone used 1.4 to check out, it won't work. On the other hand, if we distribute 1.4 and the working copy is 1.3, it might possibly break the working copy for the user by updating the repo. I don't think that will actually happen on svn info, but I haven't tried!
Regardless of whether it works now, it could be the same issue again with version 1.5, 1.8, or 2.0 any time in the future.

[tiwag]

linux and mac should always have svn commandline client installed, isn't it?
this should be true for every serious developer on windoze too 

Although it doesn't interest me what gives you the creeps,
i would simply use svn, and everyone who wants to build his own C::B from svn has to install it - basta

[afb]

I don't think requiring Subversion for compiling the nightly build
is any harder of a requirement than requiring wxWidgets installed...
The language/locale issue was a curveball, but seems sorted out.

Maybe you could also take a look at the proposed autorevision changes ?
I would like to have access to the raw rev. number, without the trunk-

Code

m4_define([SVN_REVISION], trunk-r3163)
m4_define([SVN_REV], 3163)

Code

--- configure.in        (revision 3163)
+++ configure.in        (arbetskopia)
@@ -49,6 +49,8 @@
 AC_CHECK_FUNC(snprintf, AC_DEFINE(HAVE_SNPRINTF,,snprintf))
 AC_CHECK_FUNC(vsnprintf, AC_DEFINE(HAVE_VSNPRINTF,,vsnprintf))
 
+AC_SUBST(REVISION, SVN_REV)
+
 dnl versioning info for libtool
 dnl Note this is the ABI version which is not the same as our actual library version
 CODEBLOCKS_CURRENT=0

The RPM spec is using a sed hack, but that doesn't work too good for XML...
(I want it to be able to autogenerate a codeblocks.plist, for Mac OS X)

Code

--- codeblocks.spec.in  (revision 3163)
+++ codeblocks.spec.in  (arbetskopia)
@@ -1,4 +1,4 @@
-%define _svnrev                %(echo @VERSION@ | cut -c 8-)
+%define _svnrev                @REVISION@
 %define req_wxgtk      2.6.0
 %define _fedora                %(if [ -f /etc/fedora-release ]; then echo 1; else echo 0; fi)
 %define _suse           %(if [ -f /etc/SuSE-release ]; then echo 1; else echo 0; fi)

edit: on second thought, changing SVN_REVISION is probably a little confusing.
Not to mention that the variable and define having the same name doesn't work.

[afb]

linux and mac should always have svn commandline client installed, isn't it?

True for the latest versions, not so for older versions (it is installable...)

[thomas]

linux and mac should always have svn commandline client installed, isn't it?

This is why we are having these troubles... those are all localised.

Although it doesn't interest me what gives you the creeps, i would simply use svn, and everyone who wants to build his own C::B from svn has to install it - basta

When I first incepted autorevision, it only worked with Subversion, had no fallback, and did not do any serious error checking.
The same day (because he promptly encountered a problem), Yiannis came up with the following requirements:
1. it must not break the build
2. it must work with an exported tarball, i.e. when there is no revision information at all
3. it should work without svn or any other dependencies, having a fallback
4. it can have revision=0 as fallback if nothing else helps

Maybe you could also take a look at the proposed autorevision changes ?
I would like to have access to the raw rev. number, without the trunk-

But... that's exacly what autorevision provides? The trunk- comes from somewhere else...?

<everything else>

(pretends to understand anything you said)
Yes... that looks nice, dear.   :lol:

[Game_Ender]

I am going to have to give this a try because last time on checked, C libraries were complier independent thanks to the standard C abi.  I will see how the subversion developers managed to subvert this.

[afb]

When I first incepted autorevision, it only worked with Subversion, had no fallback, and did not do any serious error checking.
The same day (because he promptly encountered a problem), Yiannis came up with the following requirements:
1. it must not break the build
2. it must work with an exported tarball, i.e. when there is no revision information at all
3. it should work without svn or any other dependencies, having a fallback
4. it can have revision=0 as fallback if nothing else helps

Yeah, I guess we do need some kind of such workaround for Windows...
(I saw that someone was working on a replacement for wx-config too)

But... that's exacly what autorevision provides? The trunk- comes from somewhere else...?

<everything else>

(pretends to understand anything you said)
Yes... that looks nice, dear.   :lol:

Sorry, I was mixing up autorevision with update_revision.sh -
I meant "revision" handling in general, sorry for the confusion...

Autorevision only writes the src/sdk/autorevision.h header, right ?
Will do up a proper patch for the other change, to the autoconf.

[afb]

Will do up a proper patch for the other change, to the autoconf.

http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1604&group_id=5358

[Brain Damage]

yup, my local is italian and my svn client is translated in italian as well.

i updated to revision 3163 (should contain the fixes) today (1/11/06)

i tried to run the following commands:
./bootstrap
./configure --enable-contrib
until now all fine
then i tried to run make
i keep getting the error started in the first post in this thread
then i tried anoter way:
make dist
it created correctly the tar package
i tried to copy to my rpm source folder & create the rpm:

sudo mv codeblocks-trunk-r$REVISION.tar.gz $RPM_TOPDIR/SOURCES
rpmbuild -bs codeblocks.spec

but i did get the following error:

error: Package already exists: %package debug (but no package is present, the folder is empty)

(this probably since i tried before to force to install a rpm nighty build)

trying to not loose hopes i extractied the tar package in a folder and i did run:

./configure --enable-contrib
make (this time it compiled correctly)
# make install
the installation runs fine but when i do try to run it, it reports that it misses a file (can't find wich file)

if the make directly from the svn sources would be fixed (no more mismatching language), would i still get the same error (missing file) after compling?

[afb]

but i did get the following error:

error: Package already exists: %package debug (but no package is present, the folder is empty)

(this probably since i tried before to force to install a rpm nighty build)

This sounds like an RPM error, with the specfile on your platform.
AFAIK that debug package is a thing that SUSE/Mandriva does... ?

Code

%{?debugrpm:%debug_package}

If you list your RPM settings, it should give you some clues to how it
is trying to define the debug package in the spec ? (rpmbuild --showrc)

[Brain Damage]

i do use mandriva linux 2007 with kernel 2.6.17-5; the rpmbuild version is 4.4.6.

sorry for not being much "skilled" but i switched to linux very recently & i am not a good programmer since i only write small programs for myself when i do need (in my free time), thanks anyway for the help.

i check out the output of the rpmbuild configuration; those are the lines of codes that i belive that they define the debug package, they don't tell me much so i hope that someone may be able to understand them and tell me what's wrong (if needed, the output.txt attached file is the complete settings dump):

Code

%{nil}
-14: debug_package	
%ifnarch noarch
%global __debug_package 1
%package debug
Summary: Debug information for package %{name}
Group: Development/Debug
AutoReqProv: 0
%description debug
This package provides debug information for package %{name}.
Debug information is useful when developing applications that use this
package or when debugging this package.
%files debug -f debugfiles.list
%defattr(-,root,root)
%endif
%{nil}
-14: debugcflags	%{?_enable_debug_packages:-g}
-14: defined	%{expand:%%{?%{1}:1}%%{!?%{1}:0}}
-14: distribution	Mandriva Linux
-14: distsuffix	mdv
-14: find_lang	/usr/lib/rpm/mandriva/find-lang.sh %{buildroot}
-14: install	%{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}
%%install
[ %{_with install} -eq 1 ] || exit 0 
%{nil}
-14: ix86	i386 i486 i586 i686 pentium3 pentium4 athlon k6
-14: make	%{_make_bin} %_smp_mflags
-14: make_session	if [ -x %{_fndsession_bin} ]; then %{_fndsession_bin} || true ; fi 
%{nil}

[attachment deleted by admin]

[skoehler]

Hi!

i have a plea:
please use LANG=C on Linux.

On Gentoo Linux, the en_US profile may not be installed. Gentoo users have the choice, which locales they install, and which they don't.

I have read, that LANG=C doesn't work on Windows. Well, i have no suggestion :-(
Isn't it possible to detect Windows via configure and then use LANG=C if we have Linux, OSX, BSD, ... (and not Windows).

Well, i hope that LANG=C works on more platforms than Linux.