Re: Can't compile CVS: libvfs-mc.a undefined references
- From: Pavel Roskin <proski gnu org>
- To: Frédéric L. W. Meunier <0 pervalidus net>, "Andrew V. Samoilov" <sav bcs zp ua>
- Cc: mc-devel gnome org
- Subject: Re: Can't compile CVS: libvfs-mc.a undefined references
- Date: Sat, 21 Sep 2002 02:47:56 -0400 (EDT)
Hello!
On Sat, 21 Sep 2002, [ISO-8859-1] Frédéric L. W. Meunier wrote:
> Fresh CVS:
>
> ../vfs/libvfs-mc.a(vfs.o): In function `vfs_init':
> vfs.o(.text+0x24b6): undefined reference to `vfs_mcfs_ops'
> ../vfs/libvfs-mc.a(tcputil.o): In function `socket_read_block':
> tcputil.o(.text+0x4f): undefined reference to `tcp_invalidate_socket'
> ../vfs/libvfs-mc.a(tcputil.o): In function `socket_write_block':
> tcputil.o(.text+0xb1): undefined reference to `tcp_invalidate_socket'
> ../vfs/libvfs-mc.a(tcputil.o): In function `rpc_send':
> tcputil.o(.text+0x146): undefined reference to `tcp_invalidate_socket'
Quite obviously, it's the result of this change (vfs/ChangeLog):
2002-09-19 Andrew V. Samoilov <sav bcs zp ua>
* tcputil.c [!WITH_MCFS]: Disable mcfs related code.
* mcfs.c [!WITH_MCFS]: Disable all code.
Thank you for quick report! Andrew, please fix it and test both with and
without mcfs.
> --libdir=/usr/local/share --disable-dependency-tracking
> --disable-glibtest --disable-nls --enable-charset --with-mcfs
> --without-gpm-mouse --without-slang --with-included-slang
> --without-ext2undel
Do you really need mcfs? Are you going to use it? Are you using it
already? I'm just trying to understand, which features are useful, and
which only confuse users and need to be removed.
The whole command line is impressive. Really impressive. I think I'm
seeing something like that the fifth time during the last month.
I saw --without-ncurses, even though the documentation says that ncurses
is not used by default. Now "configure --help" says the same, and
--without-ncurses is actually handled somehow (i.e. ignored).
Then I saw somebody using "--with-termcap --with-terminfo". After seeing
that, I removed "--with-terminfo".
Then there were two other cases of --without-ncurses, one of which was
perversive enough to break compilation.
Now "--without-slang --with-included-slang". For some strange reason,
more and more users try to use all or almost all options to configure,
even though they contradict each other.
I suggest that we drop --with-slang, --with-included-slang and
--with-ncurses. Instead, there will be one option, --with-screen
(lynx uses this name already). The valid values will be "slang",
"mcslang" (i.e. included S-Lang) and "ncurses". "yes" and "no" will be
invalid, configure will abort if those values are used.
Also, --with-termcap should not force included S-Lang. It will be invalid
if the usage of termcap cannot be ensured.
I hope this will help.
--
Regards,
Pavel Roskin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]