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] * mezz7 goes check on libtool.info 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 maybe it's because FreeBSD always grab higher version? I will need to re-read ahze's thread.. 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. yeah, fun, fun... after 6.0R 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. your not alone, many didn't spot it. :-) 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. have port use it is better than global? global is better, but it'll break a lot of things basically every port which installs a versioned shared lib. right not to mention that it'd force people to rebuild all their ports to catch the new libs not only GNOME people, that is Yep, but it's a real fix for the last. :-) indeed :) but it's a real headache as well :) we can send them roses. ;-) hehe