Want to do all ltverhack on other libraries? Kind of pain to rebuild everything when we don't put ltverhack in every port at once. perhaps libgimp* i'm not sure how stable their ABI is me too if we have a feature of ltverhack:[0-9] then it would be perfect for any unstable ABI apps. then it'd have to be LTVERHACK= x:y:z not need x:y:z.. just one That's how you specify version info, though if needs x:y:z, then what's difference for .so.0? or none? libtool translates the x:y:z into a library version see "versioning" in libtool.info put ${ver}:0:0 in bsd.gnome.mk and have ltverhack:[0-9] to control the .so.[0-9] it might be that libtool is incorrectly numbering libraries, on FreeBSD freebsd-elf) major=".$current" linux) major=.`expr $current - $age` this means that on FreeBSD, the library major number will be increased even if the ABI is preserved I wonder why they thought FreeBSD would be different. i wonder, too i'll do some calculations using gtk20 as reference cool LT_VERSION_INFO = 600:9:600 that's what gtk+ 2.6.9 passes as -version-info on linux, it results in 600 - 600 = gtk-2.0.so.0 on FreeBSD, it results as 600 = gtk-2.0.so.600 this makes me think that ltmain.sh should be fixed I agree. but this will affect so many ports... Why do libtool have to be weird? 600 - 600.. couldn't it be simple to just 0? :-) However, doing so may break a lot of plists. we might want to change ltverhack to fix ltmain.sh and let ade deal with a global fix. That's doable. in this case, we might even move the fix to lthack, as it's always correct i wonder why didn't i spot this in the first place. but i came up with ltverhack, which achieves the same results using a bad method i believe the proper fix involves copying ${LTMAIN} to the port's WRKDIR and patching that copy. and having the port use it, instead of the global ltmain.sh i'll test.