Re: A proposal for Midnight Commander

[rgr sdf lonestar org (Rob Ristroph)]

>>>>> "Ali" == Ali Akcaagac <aliakc web de> writes:
Ali> 
Ali> I'm not the person writing patches which are supposed to be
Ali> rejected afterwards. I first make a proposal and if it's being
Ali> agreed on then we can talk about making patches. 

Come on, have you ever seen a project that worked like that ?
Seriously, "show me the code" is the motto of any project with more
than a handful of people, unless you are paying money.

Ali> I am willing to write a couple of parts to remove glib
Ali> dependency.

I would be interested in trying out any patches you made that removed
the glib dependency.  If two people where using it regularly and
merging in the other continuing changes, Pavel might be more
interested.  Even if you only remove some of the dependencies, maybe I
can see about the remaining ones.

I like the idea of writing very simple, but safe and bug-free, code
that depends on as few libraries as reasonably possible.

Ali> I don't know what you are using here but it's most likely NOT the
Ali> mc-4.1.40MP that I was refering to but to answer at least one
Ali> question it was stripped by me afterwards before I mentioned the
Ali> values.
Ali> 
>> libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40024000)
>> libncurses.so.5 => /lib/libncurses.so.5 (0x40048000)
>> libext2fs.so.2 => /lib/libext2fs.so.2 (0x40088000)
>> libcom_err.so.2 => /lib/libcom_err.so.2 (0x4009c000)
>> libc.so.6 => /lib/libc.so.6 (0x4009e000)
>> libgpm.so.1 => /lib/libgpm.so.1 (0x401c1000)
>> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Ali> 
Ali> Yeah only strange thing is, where did you get the glib dependency
Ali> from ?  Midnight Commander 4.1.40 MP doesn't have any glib
Ali> dependencies in it.  It doesn't link to it, it doesn't search for
Ali> it and it doesn't require it. So the only conclusion is you are
Ali> ldd'ing a totally wrong binary here.

I'm ldd'ing mc 4.6, to show you that the total number of library
dependancies in my version.  Perhaps you might check your version and
see if there are library dependancies other than glib that can be
removed by changing the parameters to ./configure.

>> Ok, but consider which is easier -- dealing with the separate
>> 4.1.40 tree, or just adding --without-x to your configure flags ?
Ali> 
Ali> I think you don't exactly know what you are writing here (no
Ali> offense but I don't know how else I can explain it). --without-x
Ali> has nothing to do with glib not staying a dependency inside mc.

No, and I wasn't implying that it did.  However, it is likely that you
can do far more shrinking of your mc by applying a few configure flags
(even if glib is still there) than you would get by removing glib,
which would require writing code.

Ali> Again, I'm not worried about the size (well not entirely
Ali> true). It doesn't really matter whether there are a few bytes
Ali> difference (as long as it's a few bytes). To say the truth
Ali> mc-4.6.0 can be stripped down to a 360376 bytes binary without
Ali> any options enabled, compiled with -Os and stripped, whereas the
Ali> mc-4.1.40MP is around 536524 bytes binary without any options,
Ali> compiled with -Os and stripped. But the glib library is around
Ali> 500kb which makes the nice stripped 360376 bytes binary of
Ali> mc-4.6.0 look like a worthless value.

On slackware 8.1 glib is 171k.  On Debian 3.0 it is 138k.  On Debian
testing it is 400k -- that's because it glib 2.0.

To get rid of a dependency on a 400k binary (glib 2.0) I would start
writing code, so I begin to see your point.  I probably would not do
it for the glib1.2, simply because I know of other trickery I can
employ to save me that much space, mainly removing stuff from the
linux kernel.

Why don't you see if you can use glib 1.2 ?  Then you can save a lot
of space without much work.  I have been able to compile mc 4.6 on
linuxes that had only the 1.2 version of glib, so I suppose the
configure scripts pick that up automatically.

--Rob