[Bf-committers] Core dump mysterium

[Meino Christian Cramer]

From: hans@lambermont.dyndns.org (Hans Lambermont)
Subject: Re: [Bf-committers] Core dump mysterium
Date: Sun, 30 Mar 2003 16:39:24 +0200

Hi Hans,

> Meino Christian Cramer wrote:
> 
> > From: hans@lambermont.dyndns.org (Hans Lambermont)
> > > Meino Christian Cramer wrote:
> > > >   configure --disable-openal
> > > ...
> > > >   So, all optimization that is active while compiling is coming "from
> > > >   inside" the source tree (as prefereces or such).
> > > 
> > > Please don't confuse the newly proposed build system with code from
> > > 'inside the source tree' ;-)
> > 
> >   Hrrrmm....I am confused....
> >   What should not confuse with what ?
> 
> The 'configure' system is not part of the original blender. It is a new
> system, proposed to replace the original blender makefiles used at
> NaN.
 
  I hope that it will happen as soon as possible: The more people
  could compile blender in a way, that no one has to guess, whether
  misfunctionality is based on a wrong compilation or a bug in the
  code, the fast blender will become a stable and reliable software.


> There are 2 make systems, completely independent of eachother.
> One is the old NaN system, not for the failt-hearted I'm told ;-) and
> the other is the new autotools system, which is not completely finished
> yet.

  What means "not completly finished"?  :

  It does not lead to funtional Makefiles (compilation breaks at some
  point)


  or


  The result of the compilation is executable but segfaults or lock
  the screen or....



> > > >   Would it be possible, that the blender sources are not
> > > >   gcc-3.2.2-ready?
> > > 
> > > hehe :) nice way of putting it. Turn it around: gcc-3.2.2 is not
> > > fully matured yet to compile gcc-2.9x (or various other non-gcc
> > > compilers) code.
> > 
> >   In other words: If you got a bold and a nut, which do not fit
> >   together: What is the wrong part ???  ;)
> 
> I think you don't get the point I'm trying to make. gcc3.x still
> contains lots of bugs.

  ...I heard other things from a distro maintainer (Rene Rebe) who
  includes gcc-3.xx into his distro already...

> NaN for one didn't compile blender with gcc3.x while it was readily
> available for a while.

  ...this doesn't not imply, that the reason is due to bugs in gcc.
  It only means, that the nut does not fit the bolt.
  With gcc-2.95.x there were some c++ constructs possible which badly
  hurd C++ as such.
  

> > > >   The same compilation algo is used on the system, where the compiled
> > > >   blender runs fine.
> > > 
> > > Ehhm, now you've got me confused. What system is this ?
> > 
> >   The one with the following config is the "blender-runs-system":
> >   CXX=gcc-2.95.3
> >   CC=gcc-3.2.2
> >   glibc2.2.5
> 
> I'm amazed ! This is very wrong. Don't try to mix gcc2.x and gcc3.x
> unless you're an expert in compilers.

  It is no problem: Put gcc-2.95 under /usr.
  Put gcc-3.2.2 under /usr/local.
  Do a ln -s /usr/local/gcc-3.2.2 /usr/local/gcc3.
  Define CXX as gcc
  Define CC as gcc3
  Remove any c++ libs from /usr/local/lib
  and your are done.

  It works even for blender.
  
  On the other hand: The "proper" installation of gcc-3.2.2 produces
  executable code for "erverything" (means everything I compiled on
  that system so far, including the whole KDE-3.1.1 package) but the
  compiled blender executable segfaults right in the beginning.
   

> Auto* ppl: why doesn't configure check its findings ?

  configure is'nt that smart as one would wish in certain situations.
  Example: Why all X-libs are found except libXext ???
  (This is valid for a different package than blender).

> > > Did you try a build using the traditional makefiles ? You can set the
> > > optimization flags in source/nan_compile.mk for the whole system per
> > > platform.
> > 
> >   I check source/nan_definitions.mk and found nothing special -- or
> >   dont understand it at all.
> 
> Read again, I wrote 'nan_compile.mk' not 'nan_definitions.mk'.

  Yes I read, but not only your mail, Hans, additionally I read the
  instructions found in the blender source tree which said one should
  adapt nan_definitions.mk to the current system -- which I tried to
  do right. 

> I'll spell it out :
> Change in the 'ifeq ($(OS),linux)' section:
>     REL_CFLAGS  += -O2
>     REL_CCFLAGS += -O2
> to
> #    REL_CFLAGS  += -O2
> #    REL_CCFLAGS += -O2
> 
> And use 'make' in blender/

  ...which lead to the error message below.

> This problem:
> 
> >   ====> make all in blender/extern
> >   mkdir: cannot create directory `/home/mccramer/data/static/home/mccramer/ZZZ/newdir/../lib/linux-glibc2.2.5-i386': No such file or directory
> 
> is because a topdir doesn't exist yet. I don't know which one, but try a
> 'mkdir -p' by hand if you don't know how to fix issues like this.

  The linux-glibc2.2.5-i386 isnt a directory...it is the libc...
  So I guesses that the makefile system got something really wrong
  here confusing dirs and files....
  But again: May be I am something but I am definitely no guru of this
  Makefile system.

> You will most probably stumble into other things the old NaN makefiles
> expect to be in place 'a' where they are in 'b' on your system.

  ...why is that so complicate?

> All in all I think you'll be happier with the autotools system. 

  ...which produces only working executables on my "wrong installed
  and mixed gcc system"...sigh

> Now if
> someone else in the know would help you configure it right you should be
> able to find out if it's optimization issues you're dealing with or not.

  I will check whether I can switch off optimization via autoconf.

> Succes !
  
  ...yes, I hope so. Thanks.

>     Hans

	  Keep Hacking!
	  Meino