Hard-coded paths to crt1.o and the like

Hard-coded paths to crt1.o and the like

[rdiezmail-emacs]

Hi all:

I recently noticed that a particular embedded development system comes with a precompiled vim, but without emacs. Such an injustice! 8-)

It turns out there is probably a reason: I've been trying to compile emacs-22.1 with a cross-compiler, and also with different native compiler and library versions, and it's not straightforward.

Apart from the following 'configure' parameter, cross-compiling and the like does not seem to be documented:

  ./configure --help
  
  [...]
  
  --host=HOST  cross-compile to build programs to run on HOST [BUILD]
  
When using a native compiler, but a different libc version to the one that's already installed, the main hurdle seems to be the hard-coded references to the follwoing files. That's also a problem when cross-compiling.

  crt1.o
  crti.o
  crtn.o

Hard-coded paths in build scripts are always a bad idea (in my opinion). Can someone introduce some environment variable that, if defined, would replace the hard-coded /usr/lib/ paths? That variable should be listed in "./configure --help", next to "LDFLAGS" and friends.  

I've already posted in this newsgroup about this issue, and e-mailed Eli Zaretskii directly, but I haven't heard since, and I'm not giving up just yet. 8-)

See the following message from Peter Brett for more information, he had already tried cross-compiling long before I did:

  http://www.groupsrv.com/computers/about161848.html
  
Many thanks in advance,
  Ruben



      Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail

Re: Hard-coded paths to crt1.o and the like

[Stefan Monnier]

> I recently noticed that a particular embedded development system comes
> with a precompiled vim, but without emacs. Such an injustice! 8-)

Better stay away from such harmful environments ;-)

> It turns out there is probably a reason: I've been trying to compile
> emacs-22.1 with a cross-compiler, and also with different native
> compiler and library versions, and it's not straightforward.

Indeed.  Cross-compiling is rarely if ever used for Emacs, so it has
very little (to say the least) testing and people don't think too hard
about it when making changes.

I think the only case I've heard of is when building a x86 target on an
amd64 system (or an x86 system on an amd64 kernel).  There may be
related situations with other systems, tho.

> Apart from the following 'configure' parameter, cross-compiling and the like does not seem to be documented:

>   ./configure --help
  
>   [...]
  
>   --host=HOST  cross-compile to build programs to run on HOST [BUILD]

Yes, that's all that should be needed [if we lived in a dreamworld,
that is].
  
> When using a native compiler, but a different libc version to the one
> that's already installed, the main hurdle seems to be the hard-coded
> references to the follwoing files.  That's also a problem when
> cross-compiling.

>   crt1.o
>   crti.o
>   crtn.o

Indeed.  Also, IIRC the configure script will occasionally *run* some
test programs to determine if some feature or bug is present, so that
may be another source of hurdles.

> Hard-coded paths in build scripts are always a bad idea (in my
> opinion).  Can someone introduce some environment variable that, if
> defined, would replace the hard-coded /usr/lib/ paths? That variable
> should be listed in "./configure --help", next to "LDFLAGS"
> and friends.

I'm not sure where those hardocded paths are located.  Also I'm
wondering if there may be a way to provide this info more generically
(e.g. if the /usr/lib should actually be found in /opt/url/lib we could
just provide a ROOT=/opt or something, maybe?).


        Stefan

Re: Hard-coded paths to crt1.o and the like

[Dan Nicolaescu]

I've cross-compiled emacs recently.  It does not work out of the box,
but it's not too hard to hack it to make it work. 

From what I remember src/prefix-args does not work because it is built
with the cross-compiler instead of the host compiler (and maybe there
was some other binary that needed the same thing).

But after you build "temacs", you need either a simulator or a real
machine to dump the image.



  > Hard-coded paths in build scripts are always a bad idea (in my
  > opinion). Can someone introduce some environment variable that, if
  > defined, would replace the hard-coded /usr/lib/ paths? That variable
  > should be listed in "./configure --help", next to "LDFLAGS" and
  > friends.

Patches are welcome!

Re: Hard-coded paths to crt1.o and the like

[Richard Stallman]

    >From what I remember src/prefix-args does not work because it is built
    with the cross-compiler instead of the host compiler (and maybe there
    was some other binary that needed the same thing).

It should be possible to change the makefiles to avoid that.