Porting vim to Astlinux
Philip Prindeville
to Astlinux (0.5).
Unfortunately, the src/auto/configure file seems to suggest (around line
2801) that cross-compiling isn't supported.
Is there a work-around to getting Vim cross-compiled?
I was a little surprised: I would have thought that when bringing up a
new machine, a lot of people would make Vim part of their early
bootstrapping process and get it into the new environment quickly...
Thanks,
-Philip
P.S. Yes, I actually did the read FAQ first, and didn't see anything on
cross-compilation...
Tony Mechelynck
If you have a C/C++ compiler and linker (such as gcc) on your astlinux box, or
if there is some known source from which you can get it, then you don't need a
cross-compiler. Just download the sources on the target machine and compile
there. See also my HowTo page
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm about compiling Vim
on Unix-like systems.
Best regards,
Tony.
--
Waste not, get your budget cut next year.
Philip Prindeville
It *is* a Unix box, but it's a run-from-flash system, and compiling on
the system (because the processors typically aren't very fast) is slow
and tedious... plus all the writing of temp files is hard on the flash
media.
Short answer: much quicker to compile on the host system.
So... there is no easy way to cross-compile then? The host platform is
Linux Fedora Core 7...
-Philip
Tony Mechelynck
If the existing configure script and top-level Makefile aren't what you want,
maybe you can construct a "special-purpose" makefile, maybe src/Make_ast.mak
or something? It wouldn't be the first case: after all, compiling on Cygwin
for use on native-Windows (using src/Make_cyg.mak) can also be considered a
"cross-compile".
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
164. You got out to buy software, instead of going out for a beer.
Philip Prindeville
Well, I'm a little confused... the configure that was distributed seems
to very deliberately go out of its way to defeat cross-compilation, as
opposed to simply being unaware of it (agnostic).
I was wondering if there were historical reasons for that.
-Philip
Tony Mechelynck
I don't know; but the various makefiles in the src/ subdirectory (other than
src/Makefile) bypass configure completely: when using them (e.g. to compile
Vim using various Windows compilers), configure is not used at all. If you
create a new (let's say) src/Make_ast.mak, you could do the same, using Make
variables (which can be set by environment variables) for any "user-settable"
options (such as, e.g., the tiny/small/normal/big/huge featureset, console Vim
or gvim, do or don't include MzScheme/Perl/Python/Ruby/Tcl interfaces and
where are their libraries, etc.). See the various src/Make_*.mak for examples,
and in particular Make_cyg.mak which runs on Windows but in a Unix-like
environment, and cross-compiles a Vim for native-Windows.
Best regards,
Tony.
--
First Law of Procrastination:
Procrastination shortens the job and places the responsibility
for its termination on someone else (i.e., the authority who imposed
the deadline).
Ben Schmidt
> to very deliberately go out of its way to defeat cross-compilation, as
> opposed to simply being unaware of it (agnostic).
>
> I was wondering if there were historical reasons for that.
Possibly. Or maybe it's just the way autoconf works--it has cross-compilation
options available by default, so if you don't support them, it may be smartest to
make a point of not supporting them. I don't think the way Vim uses configure is
quite standard, either, so that may have something to do with it.
I'm sure there's no good reason Vim couldn't be cross compiled. It would take
considerable effort, though. But then cross-compilation almost always does!
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Ben Schmidt
> src/Makefile) bypass configure completely: when using them (e.g. to compile
> Vim using various Windows compilers), configure is not used at all. If you
> create a new (let's say) src/Make_ast.mak, you could do the same, using Make
> variables (which can be set by environment variables) for any "user-settable"
> options (such as, e.g., the tiny/small/normal/big/huge featureset, console Vim
> or gvim, do or don't include MzScheme/Perl/Python/Ruby/Tcl interfaces and
> where are their libraries, etc.). See the various src/Make_*.mak for examples,
> and in particular Make_cyg.mak which runs on Windows but in a Unix-like
> environment, and cross-compiles a Vim for native-Windows.
This would be an advisable approach, i.e. starting with a Makefile, not with
./configure.
I believe this would be relatively easy, too, as I believe Vim has used
./configure only relatively recently, so won't rely so heavily upon it as other
projects do.
Marc Haisenko
Well, VIM cross-compiles quite nicely, haven't had an issues yet (I'm
cross-compiling to x86, PowerPC and ARM5). I've posted a patch a while ago to
fix configure.in.
The patch includes a README.
Marc
--
Marc Haisenko
Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany
Tel.: +49 (0)89 548 433 321
Philip Prindeville
> Sorry, forgot to attach the patch.
>
>
Thanks. Tried it out.
I guess since you wrote it, someone added:
{ echo "$as_me:$LINENO: checking quality of toupper" >&5
echo $ECHO_N "checking quality of toupper... $ECHO_C" >&6; }
if test "$cross_compiling" = yes; then
{ { echo "$as_me:$LINENO: error: failed to compile test program" >&5
echo "$as_me: error: failed to compile test program" >&2;}
{ (exit 1); exit 1; }; }
else
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h. */
_ACEOF
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
...
Bunch of other places, too:
{ echo "$as_me:$LINENO: checking whether we talk terminfo" >&5
echo $ECHO_N "checking whether we talk terminfo... $ECHO_C" >&6; }
if test "$cross_compiling" = yes; then
{ { echo "$as_me:$LINENO: error: failed to compile test program." >&5
echo "$as_me: error: failed to compile test program." >&2;}
{ (exit 1); exit 1; }; }
else
cat >conftest.$ac_ext <<_ACEOF
/* confdefs.h. */
_ACEOF
cat confdefs.h >>conftest.$ac_ext
cat >>conftest.$ac_ext <<_ACEOF
...
Sigh. Too bad. I'm just compiling from one version of Linux to another...
Actually, both are 2.6.x (where x>=18)... only difference is the version
of libc and the processor family (i586 vs. x86_64).
Looking at this madness, I don't know why we don't just have something
like (pardon the poor sh scripting... I'm a tcsh/perl user myself):
xcomp_default=0 # can be zero or one
as_func_xcomp_default () {
if test "$cross_compiling" = yes; then
return $xcomp_default
else
return 2
fi
}
Then you could call as_func_xcomp_default, and if the return value is 0,
default the feature off, if it's one, enable it, and for 2 have to do
the auto-discovery logic natively...
-Philip
Marc Haisenko
>
> Marc Haisenko wrote:
> > Sorry, forgot to attach the patch.
> >
> >
>
> Thanks. Tried it out.
>
> I guess since you wrote it, someone added:
>
> { echo "$as_me:$LINENO: checking quality of toupper" >&5
> echo $ECHO_N "checking quality of toupper... $ECHO_C" >&6; }
> if test "$cross_compiling" = yes; then
> { { echo "$as_me:$LINENO: error: failed to compile test program" >&5
> echo "$as_me: error: failed to compile test program" >&2;}
> { (exit 1); exit 1; }; }
> else
> cat >conftest.$ac_ext <<_ACEOF
> /* confdefs.h. */
> _ACEOF
> cat confdefs.h >>conftest.$ac_ext
> cat >>conftest.$ac_ext <<_ACEOF
> ...
>
> Bunch of other places, too:
>
After applying my patch, have you run "autoconf" ? Otherwise the patch doesn't
do anything ;-)
Marc
Philip Prindeville
> On Thursday 13 December 2007, Philip Prindeville wrote:
>
>> Marc Haisenko wrote:
>>
>>> Sorry, forgot to attach the patch.
>>>
>>>
>>>
>> Thanks. Tried it out.
>>
>> I guess since you wrote it, someone added:
>>
>> { echo "$as_me:$LINENO: checking quality of toupper" >&5
>> echo $ECHO_N "checking quality of toupper... $ECHO_C" >&6; }
>> if test "$cross_compiling" = yes; then
>> { { echo "$as_me:$LINENO: error: failed to compile test program" >&5
>> echo "$as_me: error: failed to compile test program" >&2;}
>> { (exit 1); exit 1; }; }
>> else
>> cat >conftest.$ac_ext <<_ACEOF
>> /* confdefs.h. */
>> _ACEOF
>> cat confdefs.h >>conftest.$ac_ext
>> cat >>conftest.$ac_ext <<_ACEOF
>> ...
>>
>> Bunch of other places, too:
>>
>> [...]
>>
>
> After applying my patch, have you run "autoconf" ? Otherwise the patch doesn't
> do anything ;-)
> Marc
>
>
Sorry, was looking at the wrong log file.
Ok, got fairly far last night. Figured out that I wanted to "make
install_normal" and not "make install" to install.
But then ran into:
...
make[2]: Entering directory `/home/philipp/trunk/build_i586/vim71/runtime/doc'
/bin/sh ./installman.sh xxd /home/philipp/trunk/build_i586/root/usr/share/man/it.ISO8859-1/man1 "-it" /usr/share/vim /usr/share/vim/vim71 /usr/share/vim ../runtime/doc 644 vim vimdiff evim
creating /home/philipp/trunk/build_i586/root/usr/share/man/it.ISO8859-1/man1
/home/philipp/trunk/build_i586/root/usr/bin/vim -u NONE -esX -c "helptags ." -c quit
/bin/sh: /home/philipp/trunk/build_i586/root/usr/bin/vim: /lib/ld-uClibc.so.0: bad ELF interpreter: No such file or directory
make[2]: *** [vimtags] Error 126
make[2]: Leaving directory `/home/philipp/trunk/build_i586/vim71/runtime/doc'
make[1]: [installrtbase] Error 2 (ignored)
...
Hmmmm... Seems I need to be able to run the generated binaries locally
as part of the install process?
That could be a showstopper for cross-compilation.
Then again, the error is ignored and the install continues... how
critical is this?
-Philip
Tony Mechelynck
Installing the runtimes (as part of "make install") runs the just-compiled Vim
in order to generate the help file tags. You could either check that a help
tags file is present (but is it up to date?), use any Vim (if present) in the
$PATH, or run helptags only after installing.
Best regards,
Tony.
--
"Hit any key to continue" does _not_ mean you should hit the power switch.
Philip Prindeville
> Well, VIM cross-compiles quite nicely, haven't had an issues yet (I'm
> cross-compiling to x86, PowerPC and ARM5). I've posted a patch a while ago to
> fix configure.in.
>
> The patch includes a README.
> Marc
>
>
>
Well, it would be nice if that patch were committed into the source tree.
On an unrelated note, is there something funky about the way the
tarballs are generated?
toolchain/getter_script.sh -P /home/philipp/trunk/dl ftp://ftp.vim.org/pub/vim/unix/vim-7.1.tar.bz2
--17:32:25-- ftp://ftp.vim.org/pub/vim/unix/vim-7.1.tar.bz2
=> `/home/philipp/trunk/dl/vim-7.1.tar.bz2'
Resolving ftp.vim.org... 192.87.102.42, 192.87.102.43, 2001:610:1:80aa:192:87:102:43, ...
Connecting to ftp.vim.org|192.87.102.42|:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /pub/vim/unix ... done.
==> PASV ... done. ==> RETR vim-7.1.tar.bz2 ... done.
Length: 6,876,053 (6.6M) (unauthoritative)
100%[====================================>] 6,876,053 231.30K/s ETA 00:00
17:32:57 (223.19 KB/s) - `/home/philipp/trunk/dl/vim-7.1.tar.bz2' saved [6876053]
--17:32:58-- http://files.astlinux.org/vim-7.1.tar.bz2.sha1
=> `dl/vim-7.1.tar.bz2.sha1'
Resolving files.astlinux.org... 208.109.78.142
Connecting to files.astlinux.org|208.109.78.142|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
17:32:59 ERROR 404: Not Found.
vim-7.1.tar.bz2 verified
bzcat /home/philipp/trunk/dl/vim-7.1.tar.bz2 | tar -C /home/philipp/trunk/build_i586 -xf -
tar: Read 5120 bytes from -
touch /home/philipp/trunk/build_i586/vim71/.unpacked
Any idea why (re: the short read on "tar")?
I'm running FC7, so it's hard to believe that "tar" might have been
broken and I'm the only person to notice this...
Have you seen this before?
Setting the tar blocking factor to one (-b1) seems to fix it... (Using
-B doesn't help, however)
-Philip
Philip Prindeville
That might be a reasonable patch for the cross-compilation... use any
native vim, not the one just compiled...
Adri Verhoef
> bzcat /home/philipp/trunk/dl/vim-7.1.tar.bz2 | tar -C /home/philipp/trunk/build_i586 -xf -
> tar: Read 5120 bytes from -
>
This is not a problem. Tar doesn't complain if you decompress the .bz2 file at
first and then "tar -xf" the decompressed file (.tar). Tar doesn't know the
size of the uncompressed file (yet) when it's still compressed because Tar is
reading from stdin. Try this:
(bzcat ~/.../.../vim-7.1.tar.bz2 ; dd bs=5120 if=/dev/zero count=1 ) |
tar tvf -
Does it help?
Adri
ᴠɪᴍ ⒎ ①
Tony Mechelynck
To unpack a .tar.bz2 archive, "canonical" ways are:
(a) bunzip2 archive.tar.bz2 ; tar -xvf archive.tar
or
(b) tar -jxvf archive.tar.bz2
The -v (verbose) is optional; I use it to "see" the list of unpacked file names.
Best regards,
Tony.
--
When asked by an anthropologist what the Indians called America before
the white men came, an Indian said simply "Ours."
-- Vine Deloria, Jr.