The current pkgsrc does not build emacs (though it does build xemacs; I
prefer emacs and would like it to pull itself together).

I filed a PR (23701, I think) and this evening decided to take a stab at
finding out what is required for the "machine" definition.  It didn't look as
formidable as I initially assumed (I don't really have much low-level information
about the AMD64, and assumed that all kinds of grungy details were being used
for the elisp byte-code interpreter).

I now have a working "amd64.h" header, but my attention was also directed to
a couple of GNU/LINUX "srpm" archives for emacs on the AMD64 (or x86_64 as
they still refer to it).

By and large, I believe that their config .h header is better defined than
mine.  However, it blows up at the link stage.  The first problem is
trivial: They are trying to link against stuff in "/usr/lib64/", so I
just chopped off the silly "64" from the directory name.

The second problem is that they are linking against "crt1.o".  We have
"crti.o" and "crtn.o", but not "crt1.o".


Is this toolchain stuff?  Or do I need to go spelunking in the GNU/LINUX
realms to find out what crt1.o does different from other crts?  And
what do the NetBSD crti.o and crtn.o do specially?  I haven't had to worry
about crt stuff in ages, and *never* on a UNIX system; I've just linked
against "the" system/standard crt without even caring if there was a choice.

I assume that this really matters, since we have multiple crts, and the
GNU/LINUX guys were particular about choosing crt1.o, so I don't want to
just choose one of the ones we have and cross my fingers.  (^&


Any input would be appreciated.  Thanks.  (Should I ask on current-users
instead?)


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/