They have some tool with a totally different purpose which is also called libtool. For ``convenience'' they've renamed libtool to glibtool and libtoolize to glibtoolize. I suggest creating a libtool eclass which provides an alias for the ebuilds that complain. One ebuild that complained is: libwww
why not just alias it...
In the latest portage, according to ferringb. Hopefully will be stable soon!
Support for per profile bashrc's are in >=portage-2.0.51_pre15; looking at your profiles, I don't see any defined alias's yet. So... reopening, the portage support exists, just hasn't been taken advantage of yet :)
I've updated both macos profiles. Please test. Feel free to add other system wide aliases to the bashrc file in both macos profile dirs.
how do I tell this actually works? I cannot build glib (1.2 or somesuch) which I need for fsv. For now I linked it from fink. It may be either in the glib or it might be the alias is insufficient to build libtoolized stuff correctly.
If the program calls libtool as "./libtool" obviously aliasing doesn't help. Fink has "UpdateLibtool" variable to declare that the package needs updating libtool scripts. What "UpdateLibtool" in Fink does is to copy modified ltconfig and ltmain.sh to the build directory (${S} in Portage). The correct way (I think) for Portage is to use libtool.eclass to do that job and add "inherit libtool" for the packages we fail to build due to the libtool issue.
Actually, if you check profile.bashrc, you will see alias libtool=glibtool alias libtoolize=glibtoolize. Assuming you have a version of portage >=portage-2.0.51_pre15 it should be working.
Closing out bugs that've been resolved for a while now...
