| 1 |
On Sun, 2005-08-28 at 12:50 -0400, Mike Frysinger wrote: |
| 2 |
> On Sunday 28 August 2005 07:28 am, Martin Schlemmer wrote: |
| 3 |
> > On Sun, 2005-08-28 at 01:59 -0400, Mike Frysinger wrote: |
| 4 |
> > > On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: |
| 5 |
> > > > On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: |
| 6 |
> > > > > On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: |
| 7 |
> > > > > > Which reminds me .. anybody going to scream if I update |
| 8 |
> > > > > > elibtoolize() to be able to check if it was already run, and then |
| 9 |
> > > > > > bug the portage guys to also add it to econf() ? |
| 10 |
> > > > > |
| 11 |
> > > > > do what now ? |
| 12 |
> > > > |
| 13 |
> > > > Make econf handle elibtoolize the same way it does gnuconfig ... |
| 14 |
> > > |
| 15 |
> > > why ? this would help us embedded peeps with uclibctoolize, but other |
| 16 |
> > > than that ... maybe i just havent really sat down to figure out what |
| 17 |
> > > elibtoolize does ... |
| 18 |
> > |
| 19 |
> > Because it applies the portage/relink/whatever patches to ltmain.sh |
| 20 |
> > without the need for real libtoolize and the pains that comes with it |
| 21 |
> > and a autoreconf (due to missing macro's, broken build system, etc). |
| 22 |
> |
| 23 |
> i guess if we can clean up the output to not complain when none of the patches |
| 24 |
> are needed ... |
| 25 |
> |
| 26 |
|
| 27 |
Yeah, that is the plan. |
| 28 |
|
| 29 |
> > Note ... I really don`t think uclibctoolize and the other stuff that was |
| 30 |
> > added is really appropriate in libtool.eclass, as they touch |
| 31 |
> > config.guess, etc .. maybe it would have been better to update gnuconfig |
| 32 |
> > to try and apply the patch if in uclibc profile? |
| 33 |
> |
| 34 |
> uhh, uclibctoolize doesnt touch config.guess ... it only touches |
| 35 |
> ltconfig/configure because libtool does not know about uClibc and thus will |
| 36 |
> often disable shared library support when trying to build on a uClibc host |
| 37 |
|
| 38 |
Urk, my fault .. maybe its the macosx stuff then. Either way, how about |
| 39 |
integrating them rather with the default way elibtoolize() work? If you |
| 40 |
guys are game, I can do it so that the old still will work, and we can |
| 41 |
then drop the call to it and elibtoolize once its integrated into |
| 42 |
econf(). |
| 43 |
|
| 44 |
|
| 45 |
-- |
| 46 |
Martin Schlemmer |
Archives