159584 2006-12-31 10:14 0000 app-editors/emacs-cvs (probably emacs too) requires a bit of love for FreeBSD support 2009-01-23 06:35:26 0000 1 1 1 Unclassified Gentoo/Alt FreeBSD unspecified Sparc FreeBSD RESOLVED FIXED P2 normal --- 1 flameeyes@gentoo.org bsd@gentoo.org bluebird@gentoo.org emacs@gentoo.org flameeyes@gentoo.org 2006-12-31 10:14:09 0000 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 flameeyes@gentoo.org 2006-12-31 10:15:27 0000 Created an attachment (id=105057) emacs-cvs-freebsd-sparc.patch flameeyes@gentoo.org 2007-01-02 13:12:29 0000 Committed in main portage, thanks Matthew. ulm@gentoo.org 2008-03-23 19:39:20 0000 (In reply to comment #1) > Created an attachment (id=105057) [edit] > emacs-cvs-freebsd-sparc.patch Diego, was this reported upstream? ulm@gentoo.org 2008-09-04 11:14:30 0000 > > emacs-cvs-freebsd-sparc.patch > Diego, was this reported upstream? *bump* ulm@gentoo.org 2008-10-21 21:11:12 0000 Created an attachment (id=169350) 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 ulm@gentoo.org 2008-11-01 09:25:07 0000 Reopening. bluebird@gentoo.org 2008-12-16 21:51:08 0000 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. ulm@gentoo.org 2008-12-17 07:53:16 0000 (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? bluebird@gentoo.org 2008-12-17 08:30:01 0000 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. bluebird@gentoo.org 2008-12-17 08:35:20 0000 > 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 ulm@gentoo.org 2008-12-17 09:01:22 0000 So the conclusion is to use patch-src-alloc.c (attachment 169350) instead of the current solution? GCC 3 has no sparc-fbsd keyword anyway. bluebird@gentoo.org 2008-12-17 09:02:34 0000 right :) ulm@gentoo.org 2008-12-17 09:55:50 0000 Fixed in CVS, thanks again. ulm@gentoo.org 2008-12-19 18:52:40 0000 In fact this was submitted upstream long time ago, but got lost: http://thread.gmane.org/gmane.emacs.devel/61722 ulm@gentoo.org 2009-01-23 06:35:26 0000 Patch was applied upstream: <http://cvs.savannah.gnu.org/viewvc/emacs/src/alloc.c?root=emacs&r1=1.445&r2=1.446> 105057 2006-12-31 10:15 0000 emacs-cvs-freebsd-sparc.patch emacs-cvs-freebsd-sparc.patch text/plain SW5kZXg6IGVtYWNzL3NyYy9hbGxvYy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGVtYWNzLm9yaWcvc3JjL2Fs bG9jLmMKKysrIGVtYWNzL3NyYy9hbGxvYy5jCkBAIC00NTIyLDcgKzQ1MjIsNyBAQCBtYXJrX3N0 YWNrICgpCiAgIC8qIEZpeG1lOiBDb2RlIGluIHRoZSBCb2VobSBHQyBzdWdnZXN0cyBmbHVzaGlu ZyAod2l0aCBgZmx1c2hycycpIGlzCiAgICAgIG5lZWRlZCBvbiBpYTY0IHRvby4gIFNlZSBtYWNo X2RlcC5jLCB3aGVyZSBpdCBhbHNvIHNheXMgaW5saW5lCiAgICAgIGFzc2VtYmxlciBkb2Vzbid0 IHdvcmsgd2l0aCByZWxldmFudCBwcm9wcmlldGFyeSBjb21waWxlcnMuICAqLwotI2lmZGVmIHNw YXJjCisjaWYgZGVmaW5lZChzcGFyYykgJiYgIWRlZmluZWQoX19GcmVlQlNEX18pCiAgIGFzbSAo InRhIDMiKTsKICNlbmRpZgogCg== 169350 2008-10-21 21:11 0000 patch-src-alloc.c patch-src-alloc.c text/plain LS0tIHNyYy9hbGxvYy5jLm9yaWcJMjAwOC0wMS0wMiAxNDo0NTo0OC4wMDAwMDAwMDAgKzAyMDAK KysrIHNyYy9hbGxvYy5jCTIwMDgtMDEtMDIgMTQ6NDE6MjEuMDAwMDAwMDAwICswMjAwCkBAIC00 NTMyLDggKzQ1MzIsMTIgQEAKICAgICAgbmVlZGVkIG9uIGlhNjQgdG9vLiAgU2VlIG1hY2hfZGVw LmMsIHdoZXJlIGl0IGFsc28gc2F5cyBpbmxpbmUKICAgICAgYXNzZW1ibGVyIGRvZXNuJ3Qgd29y ayB3aXRoIHJlbGV2YW50IHByb3ByaWV0YXJ5IGNvbXBpbGVycy4gICovCiAjaWZkZWYgc3BhcmMK KyNpZmRlZiBfX3NwYXJjNjRfXworICBhc20gKCJmbHVzaHciKTsKKyNlbHNlCiAgIGFzbSAoInRh IDMiKTsKICNlbmRpZgorI2VuZGlmCiAKICAgLyogU2F2ZSByZWdpc3RlcnMgdGhhdCB3ZSBuZWVk IHRvIHNlZSBvbiB0aGUgc3RhY2suICBXZSBuZWVkIHRvIHNlZQogICAgICByZWdpc3RlcnMgdXNl ZCB0byBob2xkIHJlZ2lzdGVyIHZhcmlhYmxlcyBhbmQgcmVnaXN0ZXJzIHVzZWQgdG8K