Re: [Fink-devel] librasterlite2
On Sun, 20 Oct 2013 11:45:21 -0400, Jack Howarth howa...@bromo.med.uc.edu wrote: Baba, There are few issues which should be addressed in librasterlite2.info. While you are upgrading dependencies, please fix the following mistakes: SetCPPFLAGS: -I%i/include is clearly wrong. That means you are virtually guaranteed to get the wrong headers if testing alternate build options in succession. The current build will see the previous one's InstallScript results in preference to the current one. And: SetCPPFLAGS: -I%p/include is already automatically passed there as the default. No need to pass it twice. This package also fails Shlibs Policy. You're not allowed to list a file in the Shlibs field if that filename does not actually exist in the package. So: Shlibs: !%p/lib/librasterlite.2.dylib in %N when %p/lib/librasterlite.2.dylib is in %N-shlibs is not right. You even already list the file in the Shlibs entry of %N-shlibs. And that entry: Shlibs: %p/lib/librasterlite.2.dylib 3.0.0 %n (= 1.1g-1) 32 looks suspicious. 'lipo -info' says the file is actually 64-bit not 32-bit (and it should have semed *really* weird to claim a 32-bit library in a 64-bit distro anyway). Is the install_name_tool trick really needed? During the compile phase, I see: libtool: link: gcc -dynamiclib -o .libs/librasterlite.2.dylib .libs/rasterlite_io.o .libs/rasterlite_image.o .libs/rasterlite_aux.o .libs/rasterlite_quantize.o .libs/rasterlite_gif.o .libs/rasterlite_png.o .libs/rasterlite_jpeg.o .libs/rasterlite_tiff.o .libs/rasterlite_version.o .libs/rasterlite.o -L/sw/lib /sw/lib/libsqlite3.dylib -lm /sw/lib/libpng15.dylib /sw/lib/libspatialite.dylib /sw/lib/libgeotiff.dylib /sw/lib/libproj.dylib /sw/lib/libtiff.dylib /sw/lib/libjpeg.dylib -lz -O2 -pthread -install_name /sw/lib/librasterlite.2.dylib -compatibility_version 3 -current_version 3.0 -Wl,-single_module so install_name is already being correctly set. If something is breaking or resetting it later, please document it so others will not be confused (and maybe even know how to fix it). dan -- Daniel Macks dma...@netspace.org -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] librasterlite2
On Mon, 21 Oct 2013 03:03:05 -0400, Daniel Macks dma...@netspace.org wrote: On Sun, 20 Oct 2013 11:45:21 -0400, Jack Howarth howa...@bromo.med.uc.edu wrote: Baba, There are few issues which should be addressed in librasterlite2.info. While you are upgrading dependencies, please fix the following mistakes: SetCPPFLAGS: -I%i/include is clearly wrong. That means you are virtually guaranteed to get the wrong headers if testing alternate build options in succession. The current build will see the previous one's InstallScript results in preference to the current one. And: SetCPPFLAGS: -I%p/include is already automatically passed there as the default. No need to pass it twice. This package also fails Shlibs Policy. You're not allowed to list a file in the Shlibs field if that filename does not actually exist in the package. So: Shlibs: !%p/lib/librasterlite.2.dylib in %N when %p/lib/librasterlite.2.dylib is in %N-shlibs is not right. I just noticed that this even trips a validator warning on the .deb. Definitely a bad idea to commit a package that does not pass validator without getting a second opinion on whether it is a package mistake or a validator mistake. You even already list the file in the Shlibs entry of %N-shlibs. And that entry: Shlibs: %p/lib/librasterlite.2.dylib 3.0.0 %n (= 1.1g-1) 32 looks suspicious. 'lipo -info' says the file is actually 64-bit not 32-bit (and it should have semed *really* weird to claim a 32-bit library in a 64-bit distro anyway). Is the install_name_tool trick really needed? During the compile phase, I see: libtool: link: gcc -dynamiclib -o .libs/librasterlite.2.dylib .libs/rasterlite_io.o .libs/rasterlite_image.o .libs/rasterlite_aux.o .libs/rasterlite_quantize.o .libs/rasterlite_gif.o .libs/rasterlite_png.o .libs/rasterlite_jpeg.o .libs/rasterlite_tiff.o .libs/rasterlite_version.o .libs/rasterlite.o -L/sw/lib /sw/lib/libsqlite3.dylib -lm /sw/lib/libpng15.dylib /sw/lib/libspatialite.dylib /sw/lib/libgeotiff.dylib /sw/lib/libproj.dylib /sw/lib/libtiff.dylib /sw/lib/libjpeg.dylib -lz -O2 -pthread -install_name /sw/lib/librasterlite.2.dylib -compatibility_version 3 -current_version 3.0 -Wl,-single_module so install_name is already being correctly set. If something is breaking or resetting it later, please document it so others will not be confused (and maybe even know how to fix it). dan -- Daniel Macks dma...@netspace.org -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] [fink] Selfupdate-git and -svn, take two (#78)
On 10/17/2013 10:44 PM, Charles Lepple wrote: [This was originally a discussion on a GitHub pull request, but I feel like it is a little tangential to the original pull request, and potentially interesting to others testing selfupdate-git.] https://github.com/fink/fink/pull/78#issuecomment-25298485 I wrote: @fingolfin said: One part is getting this out to users. I imagine this would work as follows: ... 2. We post a (last, up to fixes) update of fink.info with this code to dists, enabling selfupdate-git Aside from switching the dists from CVS to Git, this is a big hurdle for testing. I haven't tested with this rebased branch, but the original selfupdate-git injected fink code would get blown away during a selfupdate when a new fink.info was checked in. I suspect I might have been doing something wrong there, though. Is there some other way to pin the git-enabled fink package during testing? @akhansen said: My guess is that the version noted in the VERSION file is lower than the current released version. This sets the version that gets encoded in your local .info file. It took me a little while to figure out that AKH is referring to VERSION in fink, not $prefix/fink/dists. What is the recommended way to update the selfupdate-git version of fink itself? You should be able to just take the Fink git clone that you have (for the right branch), 'git pull' to grab the latest changes from that branch, followed by running './inject' from inside the git directory. Hanspeter -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
