Subject: libtoolization ?

From: Olivier Chapuis <[email-masked]>
Date: Fri, 29 Mar 2002 16:29:59 +0100

Hello,

At present time the fvwm lib is used in a totally static way.
Moreover, an external module should be compiled inside the fvwm
source tree to take advantage of the libs.

One way to overcome these is to "libtoolize" fvwm by using the
libtool package (say version 1.4). These means that we have 
two new configuration options --disable-shared and --disable-static
(or maybe better (reversed) default is --enable-shared and
--disable-static)

- if shared is enabled (and the system support shared lib) fvwm
will build and install a sharable library libfvwm.so-version and
fvwm2 and the modules will be dynamically linked to this library.
Of course the system must be able to perform the dynamic link
(e.g., for Linux either updating /etc/ld.so.conf and run ldconfig
or adding the directory "lib" directory in LD_LIBRARY_PATH after
the install).

- if static is enable a lib archive libfvwm.a (and libfvwm.la)
will be build and installed. Moreover, if shared is disabled
fvwm2 and the modules will be statically linked against the
lib (so we will build the same type of executable as now).
It seems that during alpha devel phase the default should
be: static enabled / shared disabled.

- In "any" cases the fvwm libs headers will be installed
under includdir/fvwm/. Of course this is not needed for
running fvwm. Also if shared, libfvwm.a is not really needed
for running fvwm. So we may want to add a new config option
--disable-devel (or --enable-devel) that will cause fvwm to
install only what it is needed for running fvwm (maybe a bit
tricky).

For more details: "info libtool".

I made a few experimentation (I currently run a shared version
of fvwm :o). Attached to this message there is some memory
experimentations. I was surprised that the shared version
of fvwm used a few more memory than the static one. Any way
I do not know a lot of things on memory management (any good
doc and better tool than top and free?).

Here one of this experimentation:

---
At fvwm startup:
                          static                          shared
              SIZE SWAP  RSS SHARE    REAL  SIZE SWAP  RSS SHARE    REAL

fvwm2:        3180    0 3180  1980   (1200) | 3248    0 3248  2036  (1212)
FvwmIconMan:  1976    0 1976  1452    (524) | 2072    0 2072  1516  (556)  
FvwmPager1:   1944    0 1944  1444    (500) | 2076    0 2076  1524  (552) 
FvwmPager2:   1940    0 1940  1436    (504) | 2052    0 2052  1516  (536)
FvwmButtons1: 1896    0 1896  1420    (476) | 1996    0 1996  1484  (512)
FvwmButtons2: 1408    0 1408  1096    (312) | 1524    0 1524  1172  (352)
FvwmTheme:    1012    0 1012   768    (224) | 1292    0 1292   956  (336)
FvwmAnimate:   852    0  852   724    (128) | 1096    0 1096   872  (224)
FvwmBacker:    796    0  796   680    (116) | 1080    0 1080   868  (212)

After using a program that take all my mem (mem+swap) and playing a bit
with each modules (not very formal):

                          static                          shared

fvwm2:        2896  240 2656  1608 (1288) | 2672  244 2428  1580 (1092)
FvwmPager:    1140  272  868   712  (428) | 1120  348  772   688  (432)
FvwmIconMan:   956  332  624   496  (460) | 1112  312  800   672  (440)
FvwmTheme:     752  136  616   280  (472) |  868  236  632   308  (560)
FvwmButtons:   932  340  592   528  (404) |  952  404  548   484  (468)
FvwmPager:     916  364  552   472  (444) | 1156  344  812   720  (436)
FvwmButtons:   588  236  352   304  (284) |  692  256  436   380  (312)
FvwmAnimate:   296   80  216   200   (96) |  684  104  580   544  (140)
FvwmBacker:    224   80  144   128   (96) |  332  168  164   144  (188)

REAL is SIZE - SHARE
Note: I use --enable-xft and a  big part of the shared mem come from
Xft, around 500k for fvwm2 at startup. 
---

So the difference is not big when you really use fvwm.

So now the big question: should I finish the libtoolization of fvwm
and commit the change?

Olivier

---

From: Dan Espen <[email-masked]>
Date: Fri, 29 Mar 2002 11:07:19 -0500

> source tree to take advantage of the libs.
...
> Any way
...
> So now the big question: should I finish the libtoolization of fvwm

It doesn't seem to be buying us much.

If you have access to Solaris, you can get some nice information
from "pmap".  Heres the output for a currently running copy
of fvwm2:

fork> pmap 387
387:    /opt/public/src/fvwm/2.5.0/fvwm2
00010000    672K read/exec         /opt/public/src/fvwm/2.5.0/fvwm2
000C6000     16K read/write/exec   /opt/public/src/fvwm/2.5.0/fvwm2
000CA000    496K read/write/exec     [ heap ]
FEFE0000     16K read/exec         /usr/lib/libmp.so.2
FEFF4000      8K read/write/exec   /usr/lib/libmp.so.2
FF000000    664K read/exec         /usr/lib/libc.so.1
FF0B6000     24K read/write/exec   /usr/lib/libc.so.1
FF0BC000      8K read/write/exec   /usr/lib/libc.so.1
FF0D0000     72K read/exec         /usr/openwin/lib/libdga.so.1
FF0F2000      8K read/write/exec   /usr/openwin/lib/libdga.so.1
FF100000    552K read/exec         /usr/lib/libnsl.so.1
FF19A000     32K read/write/exec   /usr/lib/libnsl.so.1
FF1A2000     32K read/write/exec   /usr/lib/libnsl.so.1
FF1C0000     16K read/exec         /usr/platform/sun4u/lib/libc_psr.so.1
FF1D0000     88K read/exec         /usr/lib/libm.so.1
FF1F4000      8K read/write/exec   /usr/lib/libm.so.1
FF200000    560K read/exec         /usr/openwin/lib/libX11.so.4
FF29C000     24K read/write/exec   /usr/openwin/lib/libX11.so.4
FF2C0000      8K read/write/exec     [ anon ]
FF2D0000     40K read/exec         /usr/lib/libsocket.so.1
FF2EA000      8K read/write/exec   /usr/lib/libsocket.so.1
FF2F0000     96K read/exec         /usr/openwin/lib/libXext.so.0
FF318000      8K read/write/exec   /usr/openwin/lib/libXext.so.0
FF320000     80K read/exec         /usr/openwin/lib/libICE.so.6
FF344000      8K read/write/exec   /usr/openwin/lib/libICE.so.6
FF346000      8K read/write/exec   /usr/openwin/lib/libICE.so.6
FF350000     40K read/exec         /usr/openwin/lib/libSM.so.6
FF36A000      8K read/write/exec   /usr/openwin/lib/libSM.so.6
FF370000     56K read/exec         /opt/public/lib/libXpm.so.4.10
FF38C000     16K read/write/exec   /opt/public/lib/libXpm.so.4.10
FF3A0000      8K read/exec         /usr/lib/libdl.so.1
FF3B0000      8K read/write/exec     [ anon ]
FF3C0000    128K read/exec         /usr/lib/ld.so.1
FF3E0000      8K read/write/exec   /usr/lib/ld.so.1
FFBE6000     40K read/write/exec     [ stack ]
 total     3864K

Notice how it breaks out the executable part of the image,
the stack and the heap for each library.

-- 
Dan Espen                           E-mail: [email-masked]
444 Hoes Lane  Room RRC 1C-214      Phone: (732) 699-5570
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Jason L Tibbitts III <[email-masked]>
Date: 29 Mar 2002 10:33:24 -0600

>>>>> "DE" == Dan Espen <[email-masked]> writes:

DE> If you have access to Solaris, you can get some nice information
DE> from "pmap".

In Linux, this info (and more, I think) is in /proc/$PID/maps

 - J<

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Sat, 30 Mar 2002 13:53:26 +0600

> or adding the directory "lib" directory in LD_LIBRARY_PATH after

	ELF allows to embed this directory into the binary, so there's no
need to touch either ld.so.conf or LD_LIBRARY_PATH [1].  This is achieved
with "-rpath" option to the linker.  According to Linux's ld(1), Solaris
also supports this feature, and SunOS additionaly requires "-rpath-link".
I've checked DEC OSF1 4.0 and IRIX 6.5, and both of them do support
"-rpath". In OpenBSD this switch is called "-R", but at least in 2.7
"-rpath" is also accepted for compatibility with GNU ld.

[1] Both of these decisions are not so handy: ld.so.conf is only
    root-writable, so that user wouldn't be able to install a custom
    shared copy of fvwm; LD_LIBRARY_PATH should be set (in fact, added to) 
    in the user's login file, name of which isn't known (.profile |
    .bash_profile | .zshenv | .tcshrc | .whatever ...).

	_________________________________________
	  Dmitry Yu. Bolkhovityanov
	  The Budker Institute of Nuclear Physics
	  Novosibirsk, Russia

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 30 Mar 2002 15:35:03 +0100

> It doesn't seem to be buying us much.

Hum, sorry, what do you mean exactly? It seems to me that you say
something like ... "No" o:) but I am no sure.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 30 Mar 2002 15:38:38 +0100

> "-rpath" is also accepted for compatibility with GNU ld.

Yes, thanks for the tip. If we implement shared lib we may use this
and I hope that libtool resolves all system dependent stuff (it is
one of the reason of its existence).

Olivier

---

From: Dan Espen <[email-masked]>
Date: Sat, 30 Mar 2002 10:35:14 -0500

Olivier Chapuis <[email-masked]> writes:
> something like ... "No" o:) but I am not sure.

No, I don't mean "no".

I don't know if I read your data correctly,
but it didn't look like it showed a benefit.
I only mentioned that to make sure I was reading all those
numbers correctly.

The reason I posted was to point out that you could get more
detailed data.  Jason showed how to do that on Linux.

Why would you want to do this if there's no benefit?

Still, if you want to, I won't say no.

Why?

1.  Because, in principle, I like shared libraries.
2.  If anyone doesn't like them, they can disable them.

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 30 Mar 2002 20:36:15 +0100

> but it didn't look like it showed a benefit.

Yes, it seems that there are no memory benefit. I was surprised
by that. Does someone has an explaination?
However, a benefit is to have our libs public.

> detailed data.  Jason showed how to do that on Linux.

Yes, /proc/$PID/maps gives some info but I need to write
a script that make the memory computation (only mem adress
are given). I fail to found a linux utility that do the
same job than pmap on solaris.
 
> 2.  If anyone doesn't like them, they can disable them.

I will wait an other advice.

Thanks, Olivier

---

From: Dan Espen <[email-masked]>
Date: Sat, 30 Mar 2002 15:28:03 -0500

> same job than pmap on solaris.

I would guess Perl would have something that would make it easy to
to arithmetic with hex values.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 31 Mar 2002 22:02:09 +0200

> install only what it is needed for running fvwm (maybe a bit

I see a number of reasons against a shared library:

1) It doesn't save a lot of memory.

The whole library uses 170000 bytes at the moment.  A user who has
to save memory would probably use no more than five different
modules.  Assuming that every module uses no more than 25% of the
library, (s)he'd save only about 200k.  The total size of all the
.o files of the modules is 670k.  The total size of the
executables is 1725k, so you can probably not even save a megabyte
if you run all 29 modules.  All numbers calculated on an i386 CPU
w/ Linux 2.4.something.

2) It makes fvwm a whole lot harder to maintain.

Some users will have problems linking and installing.  It is not
trivial to get fvwm and the modules running against the correct
library version.  In addition, more configure options are added.
I'd like to reduce the count of configure options that control
some internal feature that does not require external libraries to
zero (not counting debug options like xinerama emulation or
efence).  More options = more problems compiling/running fvwm.

3) Each library version is incompatible to all others.

Due to the way the library is developed, the library has to be
reinstalled every time we modify the code.

The next refers only to the idea of exporting the library headers:

4) The library interface is in no shape to be exported.

The library is just a pile of undesigned code.  The library
interface is going to be made "official" only over my dead body.
Modules that use the library belong into the source tree.
External modules are and should be limited to using the module
interface.  It is well documented and changes slowly.  By no means
are we prepared to maintaining a consistent feature set of the
current library.

> -------------------------------------------------------
> executable size:
> -------------------------------------------------------
>           static:      (strip)  | shared:       (strip)
> Modules:         9114k  1843k   |        5325k    940k
> fvwm2:           1576k   437k   |        1336k    381k
> libfvwm.so:         0k     0k   |         426k    426k
> ------------------------------------------------------
> Rtotal:         10690k  2280k   |       7 087k   1747k
>                                 |      (-3603k) (-533k)

Ah, yes.  So the we'd save about 500k *if* every single module is
run on the system.  Frankly, I think it's a waste of time to spend
work on a shared library if the gain is so small.  It seems you
did not strib libfvwm.so.  The libfvwm.a on my disk uses 170k.  I
can't imagine why a shared lib should be more than twice as large.
 
> Test: Booting, start 5 fvwm "sessions" for each open a rxvt and send
> the "free" output in a file. Then at the 5th session open top and
> xemacs and cut and past the "fvwm" top info in xemacs.

Um, what is the idea of running multiple sessions at the same
time?  Any decent OS should keep only one copy of the code in
memory, regardless of how many times you run it.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]