Re: [Fink-devel] compatibility version problem
On Sep 30, 2010 Hanspeter Niederstrasser wrote: Speex had a similar issue recently (offloaded public but unstable symbols to another dylib) but kept the install name the same. The new speex version was put into a new package name (speex3 - libspeex1) *AND* the libraries were put into a 'hidden' directory /sw/lib/libspeex1/lib (that is, not directly into /sw/lib) to avoid filename collisions while maintaining Shlibs policy. On Sep 30, 2010 Peter O' Gorman wrote: Ew! You'll have to relink the library by hand in the .info file, giving it a compatibility version = 5.0.0, or figure out how to tell cmake to use a different compatibility version. Please report this to the upstream developers, since it means that any binary that used fluidsynth-1.1.1 will need to be rebuilt to use 1.1.2 (and it seems likely that is not their intention). Many thanks all for your valuable input. FWIW, I rebuilt qsynth (while linking to the cmake-built libfluidsynth.1.dylib) and qsynth.app runs without any problem using both the coreaudio and the newly-added portaudio sound drivers. Ebrahim -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] compatibility version problem
Hello list With reference to my submission (#3074237) for fluidsynth-1.1.2, I have come across a compatibility version issue. As similarly outlined in my earlier message: http://thread.gmane.org/gmane.os.macosx.fink.devel/19813/focus=19816 using autotools for the previous version of fluidsynth-1.1.1, the compatibility version for the shared library libfluidsynth.1.dylib is /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current version 5.0.0) while building with cmake for fluidsynth-1.1.2 gives /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current version 1.4.0) So, this leads to a problem since the compatibility version is being downgraded. The reviewer has suggested that this problem can be circumvented by simply renaming the package. For example, instead of fluidsynth the new package can be called fluidsynth1. This would seem simple enough but perhaps some of you may have alternative ideas that should be considered. I would appreciate any suggestions on how I could effectively deal with this compatibility version problem. Sincerely, Ebrahim -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] compatibility version problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/10 5:08 PM, Ebrahim Mayat wrote: Hello list With reference to my submission (#3074237) for fluidsynth-1.1.2, I have come across a compatibility version issue. As similarly outlined in my earlier message: http://thread.gmane.org/gmane.os.macosx.fink.devel/19813/focus=19816 using autotools for the previous version of fluidsynth-1.1.1, the compatibility version for the shared library libfluidsynth.1.dylib is /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current version 5.0.0) while building with cmake for fluidsynth-1.1.2 gives /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current version 1.4.0) So, this leads to a problem since the compatibility version is being downgraded. The reviewer has suggested that this problem can be circumvented by simply renaming the package. For example, instead of fluidsynth the new package can be called fluidsynth1. This would seem simple enough but perhaps some of you may have alternative ideas that should be considered. I would appreciate any suggestions on how I could effectively deal with this compatibility version problem. Sincerely, Ebrahim That's probably the most straightforward way to handle the situation. You'd want to have fluidsynth1-dev and fluidsynth-dev Conflict and Replace each other, of course. You may also find it convenient to have the package which contains the executable (currently the main package) continue to be called 'fluidsynth'. This strategy requires some tricks, but is convenient for upgrades when people have the executable package installed. The easiest way to handle it would be either to have the filename for the new package be fluidsynth-1.1.2.info, or (as is more commonly done) to make the prior version fluidsynth-1.1.1.info. Changing the filename disrupts the CVS history, but that's not insurmountable. - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyjwXcACgkQB8UpO3rKjQ8NsQCglr35fFb2QxGsWjeC7jZ0QxDK mUQAoKeypQLaC8t42dniS5Qq4FDtRmIW =wdHF -END PGP SIGNATURE- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] compatibility version problem
On Sep 30, 2010, at 7:45 AM, Alexander Hansen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/10 5:08 PM, Ebrahim Mayat wrote: Hello list With reference to my submission (#3074237) for fluidsynth-1.1.2, I have come across a compatibility version issue. As similarly outlined in my earlier message: http://thread.gmane.org/gmane.os.macosx.fink.devel/19813/focus=19816 using autotools for the previous version of fluidsynth-1.1.1, the compatibility version for the shared library libfluidsynth.1.dylib is /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current version 5.0.0) while building with cmake for fluidsynth-1.1.2 gives /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current version 1.4.0) So, this leads to a problem since the compatibility version is being downgraded. The reviewer has suggested that this problem can be circumvented by simply renaming the package. For example, instead of fluidsynth the new package can be called fluidsynth1. This would seem simple enough but perhaps some of you may have alternative ideas that should be considered. I would appreciate any suggestions on how I could effectively deal with this compatibility version problem. Sincerely, Ebrahim That's probably the most straightforward way to handle the situation. You'd want to have fluidsynth1-dev and fluidsynth-dev Conflict and Replace each other, of course. I'm afraid this case is trickier than that, because the major version of the library has not changed and therefore the primary filename of the shared library has not changed. So the files in the two -shlibs splitoffs will conflict, and you can't use one to replace the other or the compatibility version will break. Would it be possible to go back to using autotools to compile the package? If not, you are going to have to modify the cmake procedures so that they produce compatibility versions in the same way as the old autotools build method did. Since I know very little about cmake, I can't give advice about how to do this. -- Dave -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] compatibility version problem
On 9/29/10 6:53 PM, David R. Morrison wrote: On Sep 30, 2010, at 7:45 AM, Alexander Hansen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/10 5:08 PM, Ebrahim Mayat wrote: Hello list With reference to my submission (#3074237) for fluidsynth-1.1.2, I have come across a compatibility version issue. As similarly outlined in my earlier message: http://thread.gmane.org/gmane.os.macosx.fink.devel/19813/focus=19816 using autotools for the previous version of fluidsynth-1.1.1, the compatibility version for the shared library libfluidsynth.1.dylib is /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current version 5.0.0) while building with cmake for fluidsynth-1.1.2 gives /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current version 1.4.0) So, this leads to a problem since the compatibility version is being downgraded. The reviewer has suggested that this problem can be circumvented by simply renaming the package. For example, instead of fluidsynth the new package can be called fluidsynth1. This would seem simple enough but perhaps some of you may have alternative ideas that should be considered. I would appreciate any suggestions on how I could effectively deal with this compatibility version problem. Sincerely, Ebrahim That's probably the most straightforward way to handle the situation. You'd want to have fluidsynth1-dev and fluidsynth-dev Conflict and Replace each other, of course. I'm afraid this case is trickier than that, because the major version of the library has not changed and therefore the primary filename of the shared library has not changed. So the files in the two -shlibs splitoffs will conflict, and you can't use one to replace the other or the compatibility version will break. Would it be possible to go back to using autotools to compile the package? If not, you are going to have to modify the cmake procedures so that they produce compatibility versions in the same way as the old autotools build method did. Since I know very little about cmake, I can't give advice about how to do this. Speex had a similar issue recently (offloaded public but unstable symbols to another dylib) but kept the install name the same. The new speex version was put into a new package name (speex3 - libspeex1) *AND* the libraries were put into a 'hidden' directory /sw/lib/libspeex1/lib (that is, not directly into /sw/lib) to avoid filename collisions while maintaining Shlibs policy. Hanspeter -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] compatibility version problem
On 09/29/2010 05:53 PM, David R. Morrison wrote: On Sep 30, 2010, at 7:45 AM, Alexander Hansen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/10 5:08 PM, Ebrahim Mayat wrote: Hello list With reference to my submission (#3074237) for fluidsynth-1.1.2, I have come across a compatibility version issue. As similarly outlined in my earlier message: http://thread.gmane.org/gmane.os.macosx.fink.devel/19813/focus=19816 using autotools for the previous version of fluidsynth-1.1.1, the compatibility version for the shared library libfluidsynth.1.dylib is /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current version 5.0.0) while building with cmake for fluidsynth-1.1.2 gives /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current version 1.4.0) Ew! You'll have to relink the library by hand in the .info file, giving it a compatibility version = 5.0.0, or figure out how to tell cmake to use a different compatibility version. Please report this to the upstream developers, since it means that any binary that used fluidsynth-1.1.1 will need to be rebuilt to use 1.1.2 (and it seems likely that is not their intention). Peter -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
