[Texmacs-dev] Re: TeXmacs 1.0-1 -ffloat-store [Q]

[Joris van der Hoeven]

> > > After removing the static flag it links fine.. are you sure you want the
> > > static link as default?
> > 
> > When using the normal configure/make procedure, we indeed use dynamic 
> > linking.
> > However, we prefer to build static rpm packages, because these are much
> > more stable from the user point of view (no problems with different
> > versions of libraries).
> 
> it is probably safer to use 'c++ -static' instead of the '-Wl' flags,
> doesn't help here (only gives different error message).

OK, please send us an appropriate entry for *m68k* in configure.in (vvv)

> > > No idea why the static libs aren't there, but there 
> > > is nothing in my gcc.spec file that would explicitly disable them so it 
> > > looks 
> > > like a gcc-3.1 bug or feature.
> > 
> > Yes, many GNU/Linux distributions do a bad job on this.
> > On i386, the static X libraries are often missing.
> 
> it is my own distribution, see linux-q40.sourceforge.net. I am currently
> testing gcc-3.1.1 prerelease and somehow it does not want to build
> the static libs.

Strange; you may also try with gcc-2.95.3, which is pritty stable.

> > This sounds like a memory allocation problem.
> > Please take a look at configure.in;
> > currently there is no *m68k* entry.
> > The problem might very well disappear
> > if you add such an entry...
> 
> the defaults for the unsupported host seem pretty reasonable
> except for some linker flags, what should be changed?

I don't know...

> m68k is bigendiean, 32 bit, no enforced alignment. One thing 
> that repeatedly bites gc systems is that guaranteed alignment 
> is 16 bit only, ie even 32 bit or larger datatypes may be 16 bit 
> aligned on stack or heap. CPU doesn't care but software that
> wants eg lowest 2 bits zero for opaque type pointers must
> ensure the alignment explicitly.

OK, so it may be worth experimenting a bit with

        src/Basic/System/fast_alloc.gen.cc

You may try to ensure the alignment of the static variable alloc_table.
Another idea is to change the routine safe_malloc and ensure that
the pointer ptr returned by malloc is well aligned.

Thanks for your assistance,

Joris