Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

As we stopped shipping csu in /usr/lib and only install it in GCC's libraries
directory, emacs now fails to build on Gentoo/FreeBSD. To resolve, the
following code is needed in src_unpack:

        sed -i -e "s:/usr/lib/crtbegin.o:$(`tc-getCC`
-print-file-name=crtbegin.o):g" \
                -e "s:/usr/lib/crtend.o:$(`tc-getCC`
-print-file-name=crtend.o):g" \
                "${S}"/src/s/freebsd.h || die "unable to sed freebsd.h
settings"

this way it will use the correct crtbegin.o and crtend.o files.

Also the attached patch is needed for emacs-cvs to work on
Gentoo/FreeBSD/SPARC64, as the trap 3 (flush registers) is not implemented in
FreeBSD (Emacs.app for instance disable that entirely).

HTH,
Diego

Created an attachment (id=105057) [details]
emacs-cvs-freebsd-sparc.patch

Committed in main portage, thanks Matthew.

(In reply to comment #1)
> Created an attachment (id=105057) [edit] [details]
> emacs-cvs-freebsd-sparc.patch

Diego, was this reported upstream?

> > emacs-cvs-freebsd-sparc.patch
> Diego, was this reported upstream?

*bump*

Created an attachment (id=169350) [details]
patch-src-alloc.c

I'm not going to (re?)submit our patch upstream, since there is also attached
solution around, and I know too little about that system to decide which patch
is better.

Attached patch is from
http://hg.hellug.gr/keramida/ports/emacs-devel/file/66695abb3cec/files/patch-src-alloc.c

Reopening.

sparc@g.o is only for linux/sparc, but I'll try to help anyway ;)

> emacs-cvs-freebsd-sparc.patch
That patch just ignores the flush window request. I don't know the emacs source
code but with this patch it might happen that registers emacs expects to be
zero are not zero.
Did you notice any problems after applying this?

> patch-src-alloc.c
This is the perfect solution, you want this ;)
Instead of using the not implemented software solution it uses the (much
faster) hardware solution.
But it needs to be compiled with gcc-4. gcc-3 doesn't define __sparc64__ on
FreeBSD and will still show the bug.

(In reply to comment #7)
> sparc@g.o is only for linux/sparc, but I'll try to help anyway ;)

Thanks a lot.

So, I'll try to make a table, where "ta 3" and "flushw" are available:

   +--------+-------+-------+
   |        |32 bit |64 bit |
   +--------+-------+-------+
   |Linux   |ta 3   |ta 3   |
   |        |       |flushw |
   +--------+-------+-------+
   |FreeBSD |ta 3   |       |
   |        |       |flushw |
   +--------+-------+-------+

Did I get this right?

> But it needs to be compiled with gcc-4. gcc-3 doesn't define __sparc64__ on
> FreeBSD and will still show the bug.

The Emacs source tests for __arch64__ elsewhere, does this work for all
compilers?

Not complety, I'll try to be more verbose:

Sparc64 (aka sparc v9) are 64bit cpus but for linux we run a 32 bit userland +
64bit kernel on it. Afaik Freebsd runs 64bit userland + 64bit kernel.
flushw is available in both 32bit and 64bit.

Ages ago there were also sparc32 (pure 32bit) cpus. We (linux) don't support
them anymore, FreeBSD never supported them.

Freebsd uses __sparc64__ to check if it's a sparc64 cpu(it's defined in both 32
and 64 bit). Linux has __sparc_v9__ defined if it's a sparc64 cpu.

__arch64__ is only defined if it's actually 64bit code(most 64bit systems have
this, except amd64). They probably use it to see if the have 64bit data types.

> Ages ago there were also sparc32 (pure 32bit) cpus. We (linux) don't support
> them anymore, FreeBSD never supported them.
And they don't have flushw, they have to use "ta 3" on linux/solaris

So the conclusion is to use patch-src-alloc.c (attachment 169350 [details]) instead of
the current solution? GCC 3 has no sparc-fbsd keyword anyway.

right :)

Fixed in CVS, thanks again.

In fact this was submitted upstream long time ago, but got lost:
http://thread.gmane.org/gmane.emacs.devel/61722

Patch was applied upstream:
<http://cvs.savannah.gnu.org/viewvc/emacs/src/alloc.c?root=emacs&r1=1.445&r2=1.446>