Re: [Fink-devel] Re: Re: Re: glut-3.7-23
Jack Howarth wrote: [] If fink's dpkg weren't so brain dead about shared library versioning While you have IMHO correctly diagnosed the idiocy of freeglut using the same name libglut.3.dylib as the old glut when it is not a binary compatible dropin replacement, you are certainly barking up the wrong tree here. I could do that and then use a correctly different version for the glut produced by freeglut (it really should be libglut.11.dylib anyway). However dpkg in fink seems unable to detect whether a package has a dependency on libglut.3.dylib or libglut.11.dylib when a package is installed. So that option is out as well. Until now (this may change in the future), Fink packages do not depend on library files or versions thereof, they depend on other Fink packages. So your statement does not make sense. Binaries OTOH, linked with one of the libglut dylibs will know exactly which one they were linked with, provided the install_name of the dylib is correct (which it probably isn't in your version). No matter what I do all the packages that use glut will need to be rebuilt so you might as well follow Redhat and Debian's lead and just toss out glut as of 10.4. I do still not understand why you don't want to follow one of the established ways of adding a package with a new version of a library to Fink. The packages using the old glut have no need to be rebuilt if you do one of the following two things: 1. (This is what has been proposed to you several times in this collection of threads): Put the freeglut dylibs into a separate directory and *most important* make their install_name reflect this path. 2. (This corresponds to what you seem to have in mind but did not implement correctly, and it corresponds to the situation of other packages like db3/db4 or libdvdnav/libdvdnav2 etc): Change the name *and the install_name* of the freeglut dylib to /sw/lib/libglut.11.dylib. In both cases, you don't touch the old libglut package except for a Conflicts/Replaces of the glut-dev and freeglut-dev packages which both will contain /sw/lib/libglut.dylib as a symlink to the respective real files. In both cases, the *-shlibs packages do not Conflict/Replace. They coexist. -- Martin --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Re: Re: glut-3.7-23
Chris, I've tried a test build of the current glut package where I have the following packaging... ...for the glut package... -rwxr-xr-x 1 root admin 744232 17 Apr 15:56 /sw/lib/glut/libglut.a lrwxr-xr-x 1 root admin 14 17 Apr 15:56 /sw/lib/libglut.a -> glut/libglut.a lrwxr-xr-x 1 root admin 20 17 Apr 15:56 /sw/lib/libglut.dylib -> glut/libglut.3.dylib ...and for glut-shlibs... -rwxr-xr-x 1 root admin 1625308 17 Apr 15:56 /sw/lib/glut/libglut.3.7.dylib lrwxr-xr-x 1 root admin 17 17 Apr 15:56 /sw/lib/glut/libglut.3.dylib -> libglut.3.7.dylib While this packaging works fine for building pymol and other things that require glut anew, it breaks copies that were built against the previous packaging since they expect to see /sw/lib/libglut.3.dylib. The only way to avoid this problem would be to move the libglut.3.dylib out of /sw/lib/glut into /sw/lib. If fink's dpkg weren't so brain dead about shared library versioning I could do that and then use a correctly different version for the glut produced by freeglut (it really should be libglut.11.dylib anyway). However dpkg in fink seems unable to detect whether a package has a dependency on libglut.3.dylib or libglut.11.dylib when a package is installed. So that option is out as well. No matter what I do all the packages that use glut will need to be rebuilt so you might as well follow Redhat and Debian's lead and just toss out glut as of 10.4. Jack --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Re: Re: glut-3.7-23
Chris, Well I did a quick test of changing the versioning and that doesn't help much under fink anyway. If I use... Package: freeglut Version: 2.2.0 Revision: 2 GCC: 3.3 Maintainer: Jack Howarth bromo.med.uc.edu> Source: mirror:sourceforge:freeglut/%N-%v.tar.gz Source-MD5: 9439b8745f443131c2dad00bc93dc0ef Patch: %n.patch Depends: %N-shlibs (= %v-%r) BuildDepends: fink (>= 0.9.9), x11-dev Conflicts: glut (<< 3.7-25) Replaces: glut (<< 3.7-25) SetCFLAGS: -O3 DocFiles: AUTHORS COPYING ChangeLog INSTALL NEWS README TODO BuildDependsOnly: True SplitOff: << Package: %N-shlibs Depends: libgl Conflicts: glut-shlibs (<< 3.7-25) Replaces: glut-shlibs (<< 3.7-25) Files: lib/lib*.*.dylib Shlibs: %p/lib/libglut.11.dylib 11.8.0 %n (>= 2.2.0-1) DocFiles: AUTHORS COPYING ChangeLog INSTALL NEWS README TODO << Description: Opengl utility toolkit DescDetail: << Freeglut is a completely OpenSourced alternative to the OpenGL Utility Toolkit (GLUT) library released under the X-Consortium license. The original GLUT library seems to have been abandoned with the most recent version (3.7) dating back to August 1998. Its license does not allow anyone to distribute modified library code. Freeglut is actively developed and doesn't suffer the license restrictions. The goal is to gradually depreciate the current glut package out of fink replacing it with freeglut. << License: OSI-Approved Homepage: http://freeglut.sourceforge.net/ with the patch... diff -uNr freeglut-2.2.0.org/src/Makefile.am freeglut-2.2.0/src/Makefile.am --- freeglut-2.2.0.org/src/Makefile.am Wed Dec 10 20:32:09 2003 +++ freeglut-2.2.0/src/Makefile.am Sun Apr 17 13:04:23 2005 @@ -36,7 +36,7 @@ # Additional linker flags # [EMAIL PROTECTED]@_la_LIBADD = $(LIBM) $(X_LIBS) -lGL -lGLU -lXext -lX11 $(LIBXXF86VM ) [EMAIL PROTECTED]@_la_LDFLAGS = -version-info 11:0:8 [EMAIL PROTECTED]@_la_LDFLAGS = -version-info 11:0:0 [EMAIL PROTECTED]@_la_CFLAGS = $(X_CFLAGS) # The resulting freeglut amd dummy glut packages do not appear to cause a pymol package previously built against the stock glut package to not install. Despite the fact that this pymol package is linked against libglut.3.dylib and I have installed a libglut.11.dylib now. I guess I had forgotten that our library dependency tracking in fink is quite so brain dead. Blah. It is interesting to note that the above patch is required to get libglut.11.dylib built. Freeglut should really be building that out of the box as far as I can see. I can't quite find the glitch in the makefiles that is causing libglut.3.8.0.dylib to be built instead of libglut.11.8.0.dylib as -version-info 11:0:8 directs. Oh, I did notice we could also just start passing --disable-replace-glut to configure and end up with libfreeglut libraries instead. Of course that means more changes for the packages that use glut. Lastly I found this web page... http://openglean.sourceforge.net/lib/index.html ...which seems to summarize the mess that glut is in. Jack --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Re: Re: glut-3.7-23
On Apr 17, 2005, at 11:55 AM, Jack Howarth wrote: Dan, What if we patch the freeglut package to build with a different shared lib version number? I think this is the main source of the confusion out there. The developers of freeglut let it create a libglut.3.x.x.so/dylib when it should have been bumped up to libglut.4.x.x.so/dylib or such rather than just libglut.3.8.0.so/ dylib. In fact that this should have been the case is clear from the answer I got from them about the compatibility version being set to 12.0.0 when building on MacOS X. bad idea Shouldn't the packaging I am suggesting (using a dummy package for glut) work if we bump up the version of libglut to force anything linked against it to get rebuilt? We need to deal with the fact that glut is an orphaned project and everyone else out there is switching to freeglut. Its just that the linux distros don't seem to be worried as much about the backward compatibility issue. Follow what we had to do to fix ncurses: keep the -dev package the same, but move the actual installed libs to a subdir of /sw/lib. -- lib-dir in configure will help. Then anything built with the new freeglut lib will be fine, and not need any changes, except a versioned dep. -chris zubrzycki - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 Isaac Newton understood the impact of the Apple. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: Re: Re: glut-3.7-23
Dan, What if we patch the freeglut package to build with a different shared lib version number? I think this is the main source of the confusion out there. The developers of freeglut let it create a libglut.3.x.x.so/dylib when it should have been bumped up to libglut.4.x.x.so/dylib or such rather than just libglut.3.8.0.so/dylib. In fact that this should have been the case is clear from the answer I got from them about the compatibility version being set to 12.0.0 when building on MacOS X. http://sourceforge.net/tracker/index.php?func=detail&aid=1033433&group_id=1032&atid=101032 Shouldn't the packaging I am suggesting (using a dummy package for glut) work if we bump up the version of libglut to force anything linked against it to get rebuilt? We need to deal with the fact that glut is an orphaned project and everyone else out there is switching to freeglut. Its just that the linux distros don't seem to be worried as much about the backward compatibility issue. Jack --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
