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 attachment 105057 [details, diff] emacs-cvs-freebsd-sparc.patch
Committed in main portage, thanks Matthew.
(In reply to comment #1) > Created an attachment (id=105057) [edit] > emacs-cvs-freebsd-sparc.patch Diego, was this reported upstream?
> > emacs-cvs-freebsd-sparc.patch > Diego, was this reported upstream? *bump*
Created attachment 169350 [details, diff] 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, diff]) 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>
