Problems compiling vim with --enable-gui on Debian 4.0
Joe Keen
down Debian 4.0 system I ran into several issues. I'm sure they're
problems with the configuration of the OS as I installed it so I'm
trying to figure out what I'm missing that vim needs.
First, by the time the configure script got to the point where it was
checking the --enable-gui argument it had been emptied even though it
did have a value at the top of the configure script. Adjusting the
configure script slightly so that --enable-gui is always true allowed
it to figure out that it could compile with GTK2 enabled. Does anyone
know what configure is looking for to determine that GUI mode is
available?
After successfully configuring and adding libraries that turned up
missing at compile time I ran into another issue with _Xmblen in scr/
auto/osdefs.h. The compiler was telling me that the defenition from
there conflicted with a definition from the X system. I took the
definition out of osdefs.h and things worked from there on out. What
set of X libraries should I have on the Debian system to make sure
that they have compatible definitions?
Michael Wagner
> While I was trying to compile vim 7.1 with gui support on a stripped
> down Debian 4.0 system I ran into several issues. I'm sure they're
> problems with the configuration of the OS as I installed it so I'm
> trying to figure out what I'm missing that vim needs.
Hello Joe,
do you need special features or why don't you use the vim7.1 packages
from backports.org?
Michael
--
This is how it happens. We get the dream, but we don't get to dictate
every step toward the dream.
-Peter McWilliams
Joe Keen
>
> do you need special features or why don't you use the vim7.1 packages
> from backports.org?
>
> Michael
I'd wanted to put together a version that had a GUI enabled along
with the Perl, Python, Ruby, Tcl, and Scheme interpreters. I didn't
see a package that had all that when poking around the Debian site,
this is the first time I've installed Debian though so I'm sure I
could have missed something. I also didn't know about backports.org
so that should help substantially.
I found an article earlier today and it mentioned a package I didn't
install myself, x-window-system-core. Installing that package fixed
the configuration and compilation problems. It sounds a tad important
though so I'm not exactly sure why X was running fine without it.
Michael Wagner
> I'd wanted to put together a version that had a GUI enabled along
> with the Perl, Python, Ruby, Tcl, and Scheme interpreters. I didn't
> see a package that had all that when poking around the Debian site,
> this is the first time I've installed Debian though so I'm sure I
> could have missed something. I also didn't know about backports.org
> so that should help substantially.
Hello Joe,
sorry, that was my fault, because I use here on my workstation Debian
unstable and the package vim-gtk put all these things together that you
want. But stable has a lot of packages for your requirement.
Still take a look at http://backports.org because you will find there
many newer versions of packages for Debian stable. There is also a wiki,
so you can put it in your /etc/apt/sources.list and still install the
packages via aptitude.
Hth Michael
--
"The tragedy of life is not that it ends so soon, but that
we wait so long to begin it."
--W. M. Lewis
Bram Moolenaar
Joe Keen wrote:
Francois Ingelrest wrote:
> I've just installed the latest Ubuntu (a RC), and of course one of my
> first move was to compile Vim. I got an error while doing this:
>
> In file included from /usr/include/X11/Intrinsic.h:56,
> from gui.h:32,
> from structs.h:81,
> from vim.h:1579,
> from buffer.c:28:
> /usr/include/X11/Xlib.h:102: error: conflicting types for '_Xmblen'
> auto/osdef.h:135: error: previous declaration of '_Xmblen' was here
>
>
> In /usr/include/X11/Xlib.h, I have this:
>
> extern int
> _Xmblen(
> #ifdef ISC
> char const *str,
> size_t len
> #else
> char *str,
> int len
> #endif
> );
>
>
> And in src/auto/osdef.h, I have the same thing:
>
> #ifdef ISC
> extern int _Xmblen __ARGS((char const *, size_t));
> #else
> /* This is different from the header but matches mblen() */
> extern int _Xmblen __ARGS((char *, size_t));
> #endif
>
>
> I had to comment the definition in osdef.h to get Vim compiled, and I
> never faced this issue previously. Any idea about what's going on?
> Maybe X headers have changed?
Are you two having the same problem?
There is a difference in the size_t and int type of the second argument.
But the idea is that these lines are removed when the function prototype
is in the header. Question is why that doesn't happen. I appear to
have the same thing in the header file and it works for me.
--
[clop clop]
GUARD #1: Halt! Who goes there?
ARTHUR: It is I, Arthur, son of Uther Pendragon, from the castle of
Camelot. King of the Britons, defeator of the Saxons, sovereign of
all England!
GUARD #1: Pull the other one!
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Joe Keen
>
> There is a difference in the size_t and int type of the second argument.
> But the idea is that these lines are removed when the function prototype
> is in the header. Question is why that doesn't happen. I appear to
> have the same thing in the header file and it works for me.
package in Debian. Commenting out the definition in osdefs.h did work
for me as well.
François Ingelrest
I think I got it.
From what I understood, osdef.h is generated by osdef.sh. At first,
when I launched the compilation, I was missing some X headers (the
xserver-xorg-dev package I think), and it seems that osdef.sh was
executed at that point. Since it did not find the headers, it kept
many definitions (including _Xmblen), and the compilation finally
failed because of the missing headers. Then I installed them, and I
think that osdef.sh was never executed after that, resulting in the
conflict.
I've just tried to execute it by hand, and it has generated an almost
empty osdef.h this time. Maybe the script should be run each time
compilation is started? BTW, I'm using aap for this.
John Little
Joe said:
... x-window-system-core. Installing that package fixed
for a header <X11/Intrinsic.h>, not finding it and deciding no X
development. Installing libxt-dev gave me the file, but it seemed to
be a rather arbitrary indicator of the presence of X. (I'd have
thought that something in libx11-dev would do that.) That header is
indeed used by vim's gui.h. What's the bet that x-window-system-core
managed to get libxt-dev for you, though I can't see it. If you're
after a minimal system perhaps you could drop x-window-system-core
(adept says it's a "transitional package for Debian Etch") and try
libxt-dev, for which adept has <X11/Intrinsic.h> as an installed file.
> It sounds a tad important though so I'm not exactly sure why X was running fine without it.
HTH, John
Tony Mechelynck
Try "make reconfig" (which should be run every time you change your Vim
configuration or install new "development" packages used by Vim). You
may need to delete src/auto/config.cache and set configure settings via
environment variables, see
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
If you have hand-edited your sources out of recognition, you may even
have to start with a fresh set.
Best regards,
Tony.
--
In Riemann, Hilbert or in Banach space
Let superscripts and subscripts go their ways.
Our asymptotes no longer out of phase,
We shall encounter, counting, face to face.
-- Stanislaw Lem, "Cyberiad"