On Fri, Mar 29, 2002 at 04:29:59PM +0100, Olivier Chapuis wrote: > 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).
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 PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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 PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
