Some applications libtoolized with an old (1.3) libtool version fail to build shared libraries on Mac OS X. Just relibtoolizing the application with Apple's own glibtool won't work: an ltconfig and ltmain.sh file need to be copied in. This issue should be solved in Mac OS X 10.4. Proposed and acceptable solutions: - ELT-patches - prep-libtool ebuild
I've created an ebuild for this. Under pvdabeel's suggestion, I will change the version to 0.1, signifying that this is really just a beta. It's a quick hack up of the necessary functionality and files. http://dev.gentoo.org/~gongloo/archive/prep-libtool/prep-libtool-0.9.ebuild Please post comments, etc.
I think eclass (libtool.eclass, put ltconfig and ltmain.sh to ELT-patches) aproach is the best. (I haven't read the meeting logs yet, so it might be discussed in the last meeting though) What's the motivation of creating an ebuild for this? One of the biggest points of using eclass is to share common functions used in various ebuilds, and this is an ideal example for that.
pvdabeel and i discussed this (as well as kito and i) and we all decided that an ebuild is the best route, for several reasons (in no particular order): versioning: eclasses wouldn't support versioning of lt{main.sh,config}. This may be a problem in the future. extenisibility: eclasses wouldn't be very useful to others. for example, if (imaginary?) gentoo-solaris ever needed the same thing, they would have to duplicate our code. hassle: adding an inherit to each and every ebuild that needs it, in addition to calling a function at the end of src_unpack, is annoying and can easily be avoided with the ebuild solution. and some other reasons i'm probably missing. comments, suggestions welcome.
Firstly, as you pointed out eclass doesn't have version number, and this might be a problem in some cases. If you cannot help using version number you can name it xxx.eclass and xxx2.eclass (like gtk-engines.eclass and gtk-engines2.eclass, or kernel.eclass and kernel-2.eclass). If you need versioning you can add ltmain.sh-1.5 or something like that, so this shouldn't be a problem. Secondly, as for extensibility, I don't get your point. We can extend libtool.eclass to incorporate Mac OS X, and that's why using existing eclass is better than creating an ebuild. If there were to be gentoo-solaris they could also extend libtool.eclass for them. In Gentoo Linux we use libtool.eclass for ltmain.sh and ltconfig things, why make things complicated? I think we better take this matter to gentoo-dev list for other people's comments. Lastly, why can you avoid adding inherit and the function (elibtoolize?)? Probablly I miss what prep-libtool ebuild does. Is it enough to emerge the ebuild to get correct ltmain.sh and ltconfig in place? (no change needed for each ebuild?) In which step prep-libtool will be executed? I thought you need to add "prep-libtool" to DEPEND (or you could add it to system profile -- which isn't so smart IMO) and put prep-libtool to where elibtoolize for Mac OS X should go.
I would have to support the ebuild idea over the eclass alternative for a number of reasons, in no particular order: 1) bloat - the total size of lt{main.sh,config} is 212k. To put this in perspective, patches over 20k are 'strongly encouraged' to be placed on a mirror instead of in the portage tree. I'd assume similar policy/guidelines apply here, since this is akin to a patch needed for macos. 2) versioning - yes we can create xxx-libtool.eclass and xxx-libtool2.eclass, but then everytime lt{main.sh,config} were updated we'd need to changed the inherit for every ebuild that needs it. This is unacceptable. With both solutions, we need to add code to ebuilds that require the fix, but with the prep-libtool.ebuild solution we only have to do this once -- there is code required for src_unpack(), but there is no inherit, as that is specifically for eclasses. 3) less code in ebuilds - see above. To answer your DEPEND question, prep-libtool.ebuild would be a part of 'System' in the macos profile, so ebuilds requiring it would not need to DEPEND on it. I know this sounds counterintuitive, but ask yourself, does every ebuild in the portage tree depend on baselayout (or some baselayout virtual for systems that provide a baselayout outside of portage)?
The only argument I agree here is size bloat. Versioning argument is invalid in this case. Of course if ltmain.sh and ltconfig provide totally new feature (and imcompatible with older version) we need to create libtool2.eclass, but in most cases you only have to update the eclass (so you can keep ebuilds up-to-date). If you want keep ebuilds up-to-date with ebuild solution you need to update system profile to have prep-libtool-whatever-version *and* users need to run `emerge system` or `emerge world`. If you want to make sure you don't break Portage tree you need to add DEPEND=">=sys-devel/prep-libtool-whatever-version-required". Remember that people will not always update all packages, while with eclass solution everyone have to update eclass when they run `emerge sync`. (so you can avoid fixing ebuilds to DEPEND on newer prep-libtool)
putting it all in an eclass and adding SRC_URI to the eclass with the src to the tarball containing the updated ltmain.sh and ltconfig will not work nicely. any time we update the tarball, we'd have to recreate digests for EACH AND EVERY package that uses the eclass. This is not acceptable, at least to me. but i do agree with usata's point on having to run emerge -u world every time there is an update for it to get installed. alas, there is a solution! as it was suggested by solar: 19:13 <@solar> or in the libtool.eclass make a DEPEND="ppc-darwin? ( 10x_really_big.libtool.sh ) ${DEPEND}" That way, we add darwinlibtoolize() to libtool.eclass, which simply extracts the tarball to ${S} (the tarball, darwin-lt-0.1.tar.bz2 should only contain ltmain.sh and ltconfig), and then add a call to darwinlibtoolize() at the bottom of elibtoolize() just like they did for uclibc. By adding a DEPEND, we get around the update problem with the ebuild solution, but we also keep versionability and minimize bloat.
Created attachment 41030 [details, diff] CONCEPTUAL Patch for libtool.eclass to DEPEND on and use prep-libtool for ppc-macos
19:16 <@gongloo> solar: who should i talk to about doing that to libtool.eclass before actually doing it? 19:22 <@solar> gongloo: talk to spanky
ok, lets clear this up ... you dont need version-eclasses you dont need to update SRC_URI of every ebuild and/or rebuild any digest(s) you dont need an ebuild the files you distribute are not ~212k, they are ~4.7k (or am i the only one who uses patches ?) the additional code added to ebuilds is unavoidable review the libtool.eclass and see how solar & i handled the libtool problems with uclibc
Created attachment 41058 [details, diff] ltconfig.patch for darwin
Created attachment 41059 [details, diff] ltmain.sh.patch for darwin
Created attachment 41199 [details, diff] libtool.eclass.diff A patch for libtool.eclass to use ${PORTDIR}/ELT-patches/darwin/ltconfig.patch and ${PORTDIR}/ELT-patches/darwin/ltmain.sh.patch. Tested against glib-1.2.10-r5.ebuild.
the use in global scope is unacceptable other than that, i havent tested it but i assume it works for you
Created attachment 41202 [details, diff] libtool.eclass.diff2 ok, I removed use in global scope. I'll test it on some other packages.
you missed what i implied ;) the 'export _S_=${LIBTOOL_CMD_SEP-\~}' should go right before the actual call to glibtoolize
I see, but "export _S_=${LIBTOOL_CMD_SEP-\~}" needs to be declared both in src_compile() and src_install(). If I put it only to src_compile() (as you suggested, before glibtoolize) glib fails to emerge during einstall. Any ideas? I'll reattach libtool.eclass to cope with ltmain.sh and ltconfig 1.2 (tested with dev-libs/gdbm).
Created attachment 41203 [details] 481-glib-1.2.10-r5.log full log of `emerge =glib-1.2.10-r5`. (search it with "failed")
Created attachment 41204 [details, diff] ltconfig-1.2.patch
Created attachment 41205 [details, diff] ltmain.sh-1.2.patch
Created attachment 41206 [details, diff] libtool.eclass.diff3 Updated to handle ltconfig<main.sh v1.2. You need to put 1tconfig.sh-{1.2,1.3}.patch and ltmain.sh-{1.2,1.3}.patch to ELT-patches/darwin (rename ltmain.sh and ltconfig posted earlier to get 1.3). Tested with dev-libs/glib, dev-libs/pth, dev-libs/gdbm and media-libs/jpeg.
Created attachment 41404 [details, diff] libtool.eclass.diff4 Moved _S_ definition to ltmain.sh, so global export is no longer necessary.
Created attachment 41406 [details, diff] ltmain.sh-1.3.patch
Created attachment 41408 [details, diff] ELT-patches/egrep/1.4.3 A patch to set ${EGREP} if it is not defined.
Created attachment 41409 [details, diff] ELT-patches/ltcc/1.4.3 A patch to set ${LTCC} if it is not defined. It defaults to ${CC-gcc}.
Tested modified libtool.eclass on gtk+-1.2.10-r11 (bug #62069) and guile-1.6.4-r1 (bug #62277). All compile fine now. I think ELT-patches/sed/1.4.3, ELT-patches/egrep/1.4.3 and ELT-patches/ltcc/1.4.3 could be combined into a single patch.
yeah, combine the ltcc/egrep ones and i think these would be ok for adding to cvs
Added to CVS. Thanks vapier :) osx porters: darwintoolize function has been added. You can call it directly to update lt{config,main.sh}, or elibtoolize calls it internally if use ppc-macos returns true.
Closing out bugs that've been resolved for a while now...
