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

[Joris van der Hoeven]

Hi Richard,

Thanks for your detailed feedback.

> trying TeXmacs-1.0.0.9 now, decided to use the flags 
> 
> %ifarch m68k
>     OPTFLAGS="-O3 -fexpensive-optimizations -fno-exceptions -fno-rtti 
> -fno-implicit-templates -m68020-60 "
> %...
> 
> Surprisingly the compilation already finished, there was another little 
> problem: libgcc_s.a is not built on my system, so the static link fails.
>
> ar -r 
> /sources/rz-rpm/BUILD/TeXmacs-1.0.0.9-src/TeXmacs-1.0.0.9/lib/libserver.a 
> Objects/server.o
> c++  Objects/texmacs.o -Wl,-Bstatic 
> -L/sources/rz-rpm/BUILD/TeXmacs-1.0.0.9-src/
> TeXmacs-1.0.0.9/lib -lserver -lglue -ledit -ltypeset -lconvert -lwindow 
> -lresour
> ce -lbasic -L/usr/X11R6/lib -lXext -lX11 -L/usr/lib -lguile 
> -L/sources/rz-rpm/BU
> ILD/guile-1.3.4/libguile -L/sources/rz-rpm/BUILD/guile-1.3.4/libguile/.libs 
> -ldl
>  -lm -ldl -o 
> /sources/rz-rpm/BUILD/TeXmacs-1.0.0.9-src/TeXmacs-1.0.0.9/bin/texma
> cs.bin
> /usr/bin/ld: cannot find -lgcc_s
> collect2: ld returned 1 exit status
> make[3]: *** 
> [/sources/rz-rpm/BUILD/TeXmacs-1.0.0.9-src/TeXmacs-1.0.0.9/bin/texm
> acs.bin]
> 
> 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).

> 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.
 
> Displaying texts works fine and even acceptable in speed, however texmacs
> segfaults very quickly when editing texts.. not useable right now.
> Typical backtrace looks like
>
> #0  0xc023a1e0 in chunk_free (ar_ptr=0xc02a51e4, p=0x80767b80) at 
> malloc.c:3097
> 3097    malloc.c: No such file or directory.
>         in malloc.c
> (gdb) up
> #1  0xc023a0f4 in __libc_free (mem=0x80767b88) at malloc.c:3023
> 3023    in malloc.c
> (gdb) 
> #2  0x80331aaa in operator delete(void*) ()
> (gdb) 
> #3  0x802e402e in XMapRaised ()
> 
> -- or ------------------
> 
> 0xc023a1e0 in chunk_free (ar_ptr=0xc02a51e4, p=0x806d0b3c) at malloc.c:3097
> 3097    malloc.c: No such file or directory.
>         in malloc.c
> (gdb) bt
> #0  0xc023a1e0 in chunk_free (ar_ptr=0xc02a51e4, p=0x806d0b3c) at 
> malloc.c:3097
> #1  0xc023a0f4 in __libc_free (mem=0x806d0b44) at malloc.c:3023
> #2  0x80331aaa in operator delete(void*) ()
> #3  0x802e402e in XMapRaised ()
> .....
> .....
> #16 0x8001b7ce in XMapRaised ()
> #17 0x8002809c in XMapRaised ()
> #18 0x803d94d8 in __gmon_start__ ()
> #19 0x80068646 in XMapRaised ()
> #20 0x8006962a in XMapRaised ()
> #21 0x8006041a in XMapRaised ()
> #22 0x803dadd0 in __gmon_start__ ()
> ---Type <return> to continue, or q <return> to quit---
> #23 0x800286f8 in XMapRaised ()
> #24 0x803d9584 in __gmon_start__ ()
> #25 0x800252aa in XMapRaised ()
> #26 0x8026c894 in XMapRaised ()
> #27 0x800037a4 in XMapRaised ()
> #28 0xc0108224 in gh_launch_pad () from /usr/lib/libguile.so.6
> #29 0xc0108174 in gh_enter () from /usr/lib/libguile.so.6
> #30 0x80004af2 in XMapRaised ()
> #31 0xc0211084 in __libc_start_main (main=0x80004ad4 <XMapRaised+6736>, 
>     argc=1, argv=0xeffff8d4, init=0x80002424 <_init>, fini=0x803ed7dc 
> <_fini>, 
>     rtld_fini=0xc0009974 <_dl_fini>, stack_end=0xeffff8d4)
>     at ../sysdeps/generic/libc-start.c:92
> 
> 
> That is a linux-m68k system with glibc-2.1.3 and X-3.3.6. From my experience
> with glibc-2.1.3 I know that it is a little less forgiving than other glibc
> versions with malloc/free problems..any idea what this could be?
> Other components of the system seem pretty stable, I have recompiled mozilla 
> and such things without problems.

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...

Thanks for your help,

Joris