Hello, Attached is an ebuild for levmar: levmar is a native ANSI C implementation of the Levenberg-Marquardt optimization algorithm. Both unconstrained and constrained (under linear equations, inequality and box constraints) Levenberg-Marquardt variants are included. The Levenberg- Marquardt (LM) algorithm is an iterative technique that finds a local minimum of a function that is expressed as the sum of squares of nonlinear functions. I suggest the sci-libs category. I'm quite new to all this ebuild stuff, hence I'm not fully confident that this submission is valid/well-done, so I'd be grateful if someone would be kind enough to check all this thoroughly and tell me what's wrong. There are two patches for this package: - 2.5-f2c_main.patch changes the "main()" function into a "MAIN__()" function in the demo program, otherwise f2c complains at link time. - 2.5-cmake.patch makes some minor changes to the CMakeLists.txt file to suppress some cmake warnings. Note: - cmake is not necessary to compile levmar, the provided Makefile does fine, so I did not include cmake in the dependencies but only use it if it's available, I don't know if that's okay. Moreover, the MIN_CMAKE variable is set to cmake-1.4 since this was the minimum version specified in a comment in the CMakeLists.txt file, but this comment might not be up-to-date. - all the dependencies that I knew of (from the levmar readme) are referenced in the ebuild, but I didn't check thoroughly for minimal required versions of these dependencies, neither did I check more deeply for other unmentioned dependencies. Please advise me if more testing needs be done about this. Regards, Quentin M.
Created attachment 233253 [details] levmar-2.5.ebuild
Created attachment 233255 [details, diff] levmar-2.5-cmake.patch
Created attachment 233257 [details, diff] levmar-2.5-f2c_main.patch
Created attachment 233259 [details] levmar-2.5 ChangeLog
Created attachment 233261 [details] levmar-2.5 metadata.xml
You're off to a good start. In the future, you don't need to supply the 'ChangeLog' or 'metadata.xml'. Those things would be handled by the maintainer. You should write the ebuild to be EAPI2 compliant, at least. The src_unpack() should be src_prepare(). You shouldn't have to explicitly call the unpack function. 'epatch' can handle multiple files, so you don't have to call it twice. In src_compile(), you have both cmake and emake compiling the source, provided that CMake makes the grade. Did you perhaps mean: src_compile() { if has_version ">=${MIN_CMAKE}" ; then cmake . || die "cmake failed" else emake || die "make failed" fi }
Hello Quentin, this would nicely integrate with bug 208359 ... Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, Michael "not a sunrise member yet" Weber. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Created attachment 235217 [details] added installation of headers i added the installation of the header files to /usr/include/levmar/*.h. this is needed for bug 208359
I have installed sci-libs/lapack-atlas, and the packages dev-libs/libf2c and dev-lang/f2c are NOT required for building levmar library. Instead, fix the Makefile (or even better, fix the cmake files to do the same, but I don't know cmake): -LAPACKLIBS_PATH=/usr/local/lib # WHEN USING LAPACK, CHANGE THIS TO WHERE YOUR COMPILED LIBS ARE! -LDFLAGS=-L$(LAPACKLIBS_PATH) -L. +#LAPACKLIBS_PATH=/usr/local/lib # WHEN USING LAPACK, CHANGE THIS TO WHERE YOUR COMPILED LIBS ARE! +#LDFLAGS=-L$(LAPACKLIBS_PATH) -L. +LDFLAGS=-L. -LAPACKLIBS=-llapack -lblas -lf2c # comment this line if you are not using LAPACK. +LAPACKLIBS=`pkg-config --libs lapack` It looks like cmake wants to link f2c for some reason, so that should be fixed, too. Also the 2.5-f2c_main.patch is not necessary, the demo program compiles and runs fine (when built by hand). See levmar FAQ for how it should be solved properly (linker), if you hit it. It is a problem with certain LAPACK/BLAS libraries and should be fixed with them. It is libf2c that requires the symbol MAIN__, for nothing. I suggest adding ~amd64 keyword (meshlab already has it and depends on this package). Btw. lapack.pc is not installed by some common distros (Ubuntu), so upstream might be reluctant to use pkg-config for lapack.
(In reply to comment #8) > Created an attachment (id=235217) [details] > added installation of headers > > i added the installation of the header files to /usr/include/levmar/*.h. this > is needed for bug 208359 This ebuild does not work: the patches are never applied, since src_prepare is an EAPI 2 feature, therefore the build will fail at: Linking C executable lmdemo /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../lib64/libf2c.so: undefined reference to `MAIN__'
(In reply to comment #6) > In src_compile(), you have both cmake and emake compiling the source, provided > that CMake makes the grade. Did you perhaps mean: > > src_compile() { > if has_version ">=${MIN_CMAKE}" ; then > cmake . || die "cmake failed" > else > emake || die "make failed" > fi > } > It appears running cmake alone does not build anything, it only creates the makefiles.
I got a problem when compiling meshlab: x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,-rpath,/usr/lib64/qt4 -shared -o libfilter_isoparametrization.so filter_isoparametrization.o moc_filter_isoparametrization.o -L/usr/lib64 -L/usr/lib64/qt4 -L../../distrib -lcommon -L/usr/lib -lGLEW -llevmar -lGLU -lGL -lQtXml -L/usr/lib64 -L/usr/lib64/qt4 -lQtOpenGL -L/usr/X11R6/lib -lQtGui -lQtCore -lgthread-2.0 -lrt -lglib-2.0 -lpthread /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/liblevmar.a(lm.o): relocation R_X86_64_32S against `dAx_eq_b_BK' can not be used when making a shared object; recompile with -fPIC /usr/lib64/liblevmar.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [../../distrib/plugins/libfilter_isoparametrization.so] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-visualization/meshlab-1.2.3a-r3/work/MeshLabSrc_AllInc_v123a/meshlab/src/meshlabplugins/filter_isoparametrization' make: *** [sub-meshlabplugins-filter_isoparametrization-make_default-ordered] Error 2 Looks like liblevmar.s is not compiled as pic, so it cannot be used in a shared library, which is exactly what meshlab tries to do. Could you add -fPIC as suggested by this error? I don't know how to try myself, because the ebuild uses cmake.
(In reply to comment #12) > I got a problem when compiling meshlab: > > x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,-rpath,/usr/lib64/qt4 -shared -o > libfilter_isoparametrization.so filter_isoparametrization.o > moc_filter_isoparametrization.o -L/usr/lib64 -L/usr/lib64/qt4 -L../../distrib > -lcommon -L/usr/lib -lGLEW -llevmar -lGLU -lGL -lQtXml -L/usr/lib64 > -L/usr/lib64/qt4 -lQtOpenGL -L/usr/X11R6/lib -lQtGui -lQtCore -lgthread-2.0 > -lrt -lglib-2.0 -lpthread > /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/../../../../x86_64-pc-linux-gnu/bin/ld: > /usr/lib64/liblevmar.a(lm.o): relocation R_X86_64_32S against `dAx_eq_b_BK' can > not be used when making a shared object; recompile with -fPIC > /usr/lib64/liblevmar.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > make[1]: *** [../../distrib/plugins/libfilter_isoparametrization.so] Error 1 > make[1]: Leaving directory > `/var/tmp/portage/sci-visualization/meshlab-1.2.3a-r3/work/MeshLabSrc_AllInc_v123a/meshlab/src/meshlabplugins/filter_isoparametrization' > make: *** [sub-meshlabplugins-filter_isoparametrization-make_default-ordered] > Error 2 > > Looks like liblevmar.s is not compiled as pic, so it cannot be used in a shared > library, which is exactly what meshlab tries to do. Could you add -fPIC as > suggested by this error? > > I don't know how to try myself, because the ebuild uses cmake. > Can't reproduce this on x86 : according to http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 3.b, this is x64-specific. The CMake file states that levmar is built as a *static* library, not a shared one : is it normal for meshlab to try and link it as a shared library ? I created a new levmar-2.5-r2.ebuild (should it remain a levmar-2.5.ebuild or is 2.5-r2 fine ?) which should be EAPI2-compliant (at least the issues pointed out by Aaron are fixed, thanks for pointing them out =) and includes the installation of the header files into /usr/include/levmar, as suggested by Simon (thanks also =). I also added the ~amd64 keyword. I confirm that CMake does not build levmar but only creates a CMake-generated nicely-colored makefile, which is why emake still needs to be called afterwards (the default provided makefile is not as colorful as the CMake-generated one but works just as fine). I also created two new make+CMake patches to build levmar as a shared library. Should this occur only when building on x64 ? Does it have a consequence not to build a static library anymore ? Should both be built (I read it was not wise as a linker could have trouble choosing between the two) ? lmdemo seems to work fine using either the static or shared library. Concerning f2c, here is what the default provided makefile for levmar states: # On systems with a FORTRAN (not f2c'ed) version of LAPACK, -lf2c is # not necessary; on others, -lf2c is equivalent to -lF77 -lI77 So I guess this depends on the version of LAPACK used. Currently I see 2 versions in Portage : lapack-reference which I have and requires f2c and lapack-atlas which I do not have and does not require f2c according to Pekka (thanks also for all your input =). Pekka, does having the f2c patch and using lapack-atlas prevent you from building levmar from ebuild ? If so, we'll likely need a USE flag to tell us whether we need f2c (and thus patch the files accordingly) or not. Or can we decide all this based upon the version of lapack installed ?
Created attachment 235435 [details] Updated ebuild : headers + EAPI 2 + shared library
Created attachment 235437 [details, diff] Patch for CMake warnings + shared library.
Created attachment 235439 [details, diff] Patch for Makefile : shared library.
(In reply to comment #13) > Can't reproduce this on x86 : according to > http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 3.b, > this is x64-specific. > The CMake file states that levmar is built as a *static* library, not a shared > one : is it normal for meshlab to try and link it as a shared library ? You are right, I'm on x86-64. AFAICT Meshlab uses levmar in a plugin, which is a shared object. Meshlab also comes bundled with its own copy of levmar, but the meshlab ebuild developers want to use system libraries. Meshlab is bug #208359 , and it is my reason for being interested in the levmar ebuild. > Concerning f2c, here is what the default provided makefile for levmar states: > # On systems with a FORTRAN (not f2c'ed) version of LAPACK, -lf2c is > # not necessary; on others, -lf2c is equivalent to -lF77 -lI77 > > So I guess this depends on the version of LAPACK used. Yeah, atlas lapack does not require explicit linking to any fortran related library, it links internally to libgfortran, so users do not have to bother. > Currently I see 2 versions in Portage : lapack-reference which I have and > requires f2c and lapack-atlas which I do not have and does not require f2c > according to Pekka (thanks also for all your input =). > > Pekka, does having the f2c patch and using lapack-atlas prevent you from > building levmar from ebuild ? If so, we'll likely need a USE flag to tell us > whether we need f2c (and thus patch the files accordingly) or not. Or can we > decide all this based upon the version of lapack installed ? No, I managed to build levmar okay with the ebuild, I just fixed the patching. Does pkg-config not work for you? If not, it should be fixed in the lapack package you use. USE-flag is too cumbersome, since the information should be available in pkg-config. As for the patching... ugh. Btw. Gentoo has 'eselect lapack', which means you can have several LAPACK implementations available and switch at will. That does not exactly help here, but I would not mind about that. It just means you cannot rely on checking the installed version of a LAPACK. Are you sure your lapack installation really requires explicit linking to f2c? That is very unfortunate due to 'eselect', wonder why it doesn't do like atlas. I'll try the new ebuild when I get a chance, thanks.
Finally I got the time to try levmar-2.5-r2 and it works fine, meshlab compiles ok and seems to run. Btw. the patch 2.5-make-shared.patch is not necessary, cmake overwrites the makefile. I removed this patch from the build before trying. Thanks.
Just noticed there's another bug which already requests this package. Please attach your ebuilds there. *** This bug has been marked as a duplicate of bug 320425 ***
