Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 65272 - older libtool doesnt recognize darwin == no shared libraries
Summary: older libtool doesnt recognize darwin == no shared libraries
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: osx porters
Depends on:
Blocks: 60580 62069 62277
  Show dependency tree
Reported: 2004-09-24 18:59 UTC by Pieter Van den Abeele (RETIRED)
Modified: 2005-02-06 13:33 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

CONCEPTUAL Patch for libtool.eclass to DEPEND on and use prep-libtool for ppc-macos (libtool.eclass.diff,539 bytes, patch)
2004-10-03 16:38 UTC, Hasan Khalil (RETIRED)
Details | Diff
ltconfig.patch for darwin (ltconfig.patch,2.50 KB, patch)
2004-10-04 05:50 UTC, SpanKY
Details | Diff for darwin (,2.18 KB, patch)
2004-10-04 05:50 UTC, SpanKY
Details | Diff
libtool.eclass.diff (libtool.eclass.diff,1.27 KB, patch)
2004-10-05 21:55 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff
libtool.eclass.diff2 (libtool.eclass.diff2,1.24 KB, patch)
2004-10-05 22:22 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff
481-glib-1.2.10-r5.log (481-glib-1.2.10-r5.log,118.70 KB, text/plain)
2004-10-05 22:56 UTC, Mamoru KOMACHI (RETIRED)
ltconfig-1.2.patch (ltconfig-1.2.patch,2.44 KB, patch)
2004-10-05 23:05 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff (,1.37 KB, patch)
2004-10-05 23:06 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff
libtool.eclass.diff3 (libtool.eclass.diff3,1.38 KB, patch)
2004-10-05 23:12 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff
libtool.eclass.diff4 (libtool.eclass.diff4,1.47 KB, patch)
2004-10-09 02:40 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff (,2.02 KB, patch)
2004-10-09 02:44 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff
ELT-patches/egrep/1.4.3 (1.4.3,387 bytes, patch)
2004-10-09 02:46 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff
ELT-patches/ltcc/1.4.3 (1.4.3,396 bytes, patch)
2004-10-09 02:48 UTC, Mamoru KOMACHI (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Pieter Van den Abeele (RETIRED) gentoo-dev 2004-09-24 18:59:41 UTC
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 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
Comment 1 Hasan Khalil (RETIRED) gentoo-dev 2004-09-25 18:24:07 UTC
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.

Please post comments, etc.
Comment 2 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-09-25 23:05:35 UTC
I think eclass (libtool.eclass, put ltconfig and 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.
Comment 3 Hasan Khalil (RETIRED) gentoo-dev 2004-09-26 10:17:58 UTC
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{,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.
Comment 4 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-09-28 02:13:14 UTC
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 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 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 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.
Comment 5 Lina Pezzella (RETIRED) gentoo-dev 2004-09-28 18:42:36 UTC
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{,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{,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)?
Comment 6 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-09-28 22:18:05 UTC
The only argument I agree here is size bloat. Versioning argument is invalid in this case. Of course if 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)
Comment 7 Hasan Khalil (RETIRED) gentoo-dev 2004-10-03 16:23:48 UTC
putting it all in an eclass and adding SRC_URI to the eclass with the
src to the tarball containing the updated 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? ( ) ${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 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.
Comment 8 Hasan Khalil (RETIRED) gentoo-dev 2004-10-03 16:38:41 UTC
Created attachment 41030 [details, diff]
CONCEPTUAL Patch for libtool.eclass to DEPEND on and use prep-libtool for ppc-macos
Comment 9 Hasan Khalil (RETIRED) gentoo-dev 2004-10-03 16:42:02 UTC
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
Comment 10 SpanKY gentoo-dev 2004-10-04 05:49:22 UTC
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
Comment 11 SpanKY gentoo-dev 2004-10-04 05:50:02 UTC
Created attachment 41058 [details, diff]
ltconfig.patch for darwin
Comment 12 SpanKY gentoo-dev 2004-10-04 05:50:54 UTC
Created attachment 41059 [details, diff] for darwin
Comment 13 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-05 21:55:41 UTC
Created attachment 41199 [details, diff]

A patch for libtool.eclass to use ${PORTDIR}/ELT-patches/darwin/ltconfig.patch
and ${PORTDIR}/ELT-patches/darwin/ Tested against
Comment 14 SpanKY gentoo-dev 2004-10-05 22:03:20 UTC
the use in global scope is unacceptable

other than that, i havent tested it but i assume it works for you
Comment 15 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-05 22:22:38 UTC
Created attachment 41202 [details, diff]

ok, I removed use in global scope. I'll test it on some other packages.
Comment 16 SpanKY gentoo-dev 2004-10-05 22:34:05 UTC
you missed what i implied ;)

the 'export _S_=${LIBTOOL_CMD_SEP-\~}' should go right before the actual call to glibtoolize
Comment 17 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-05 22:51:40 UTC
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 and ltconfig 1.2 (tested with dev-libs/gdbm).
Comment 18 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-05 22:56:04 UTC
Created attachment 41203 [details]

full log of `emerge =glib-1.2.10-r5`. (search it with "failed")
Comment 19 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-05 23:05:32 UTC
Created attachment 41204 [details, diff]
Comment 20 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-05 23:06:10 UTC
Created attachment 41205 [details, diff]
Comment 21 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-05 23:12:16 UTC
Created attachment 41206 [details, diff]

Updated to handle ltconfig& v1.2. You need to put{1.2,1.3}.patch and{1.2,1.3}.patch to ELT-patches/darwin
(rename and ltconfig posted earlier to get 1.3). Tested with
dev-libs/glib, dev-libs/pth, dev-libs/gdbm and media-libs/jpeg.
Comment 22 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-09 02:40:46 UTC
Created attachment 41404 [details, diff]

Moved _S_ definition to, so global export is no longer necessary.
Comment 23 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-09 02:44:35 UTC
Created attachment 41406 [details, diff]
Comment 24 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-09 02:46:33 UTC
Created attachment 41408 [details, diff]

A patch to set ${EGREP} if it is not defined.
Comment 25 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-09 02:48:11 UTC
Created attachment 41409 [details, diff]

A patch to set ${LTCC} if it is not defined. It defaults to ${CC-gcc}.
Comment 26 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-09 02:53:48 UTC
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.
Comment 27 SpanKY gentoo-dev 2004-10-09 10:21:55 UTC
yeah, combine the ltcc/egrep ones and i think these would be ok for adding to cvs
Comment 28 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-10 10:18:02 UTC
Added to CVS. Thanks vapier :)

osx porters: darwintoolize function has been added. You
can call it directly to update lt{config,}, or elibtoolize
calls it internally if use ppc-macos returns true.
Comment 29 Hasan Khalil (RETIRED) gentoo-dev 2005-02-06 13:33:27 UTC
Closing out bugs that've been resolved for a while now...