[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Where is the source code for fvwm95 2.0.43a?



Jor-el <jorel@ibm.net> writes:

> Darren,
> 
> 	I am not sure how to read your statements. Your first comment
> states that (contrary to my assertion) the source code distributed with
> Slink matches up with the binary version of fvwm95 that is in Slink. Your
> second comment says that the situation I described (source code mismatch)
> is a known flaw - which to me, reads like an acknolwedgement that there is
> a source code mismatch.

I think what Darren was trying to say (and he may correct me on this)
is that in general there is occasionally problems with source code
version skew, but that that isn't happening with fvwm95 in slink.

> 	Anyway, some (but not all) of the reasons I had for stating that
> there is a source code mismatch have disappeared. The source code for
> fvwm95 has a version of 2.0.43ba tagged to it. Since 'fvwm95 -version'
> returns 2.0.43a , this was one of my reasons for saying that there is a
> mismatch. However, I just discovered that the fvwm95 I built from source
> also returns a version of 2.0.43a.
> 
> 	But...
> 
> 	I still have a very large mismatch in file sizes between the
> packaged up binaries, and the binaries that I built. Can someone explain
> away these (sometimes by a factor of 10) mismatches?
> 
> Regards,
> Jor-el

That fvwm95 -version returns '2.0.43a' is a bug in the source code -
when the version number changed, it wasn't bumped in the source.  I
hadn't noticed that, and the next .deb will fix that.  To get the
version of the binary distributed with debian, either do a dpkg --info
on the .deb file, or if you have the debian binary package installed,
do a
dpkg -s fvwm95

As for the file size mismatches, are you building from source code the 
same way that the package does?  Specifically, are you running 'strip' 
on the binary after installing it?  For reference the unstripped size
of the fvwm95 binary on my system is 931306 bytes.  (Built, as policy
dictates, with -O2 -g)

If you just want to build the binary the way the package does, running
a 'debian/rules build' from the top directory of the unpacked source
will do that (although that won't do the 'strip' bit).  Also, are you
just extracting the source by extracting the .tar.gz file, or are you
also applying the .diff.gz file?  (dpkg-source -x will do this
automatically).  If you don't apply the diff, you may have some
problems building the package under glibc, specifically in the
FvwmTaskBar module.  (And although it may build, you can face some
rather serious problems on non-Intel machines if you don't apply the
diff).


Reply to: