Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: OSX

Readline issues

 

 

Gentoo osx RSS feed   Index | Next | Previous | View Threaded


grobian at gentoo

Aug 20, 2005, 8:25 AM

Post #1 of 2 (526 views)
Permalink
Readline issues

OSXians,

as you all might know, readline is not existant on your OSX box. At
least it looks like that. Apple supplies libedit and by default
symlinks it to readline in /usr/lib thereby triggering our collision
protect when emerging readline:

% la /usr/lib/libreadline.dylib
lrwxr-xr-x 1 root wheel 13 Aug 20 14:17 /usr/lib/libreadline.dylib
-> libedit.dylib

Not very interesting are this link and the libedit library, as they
don't seem to care to link some readline.h file in
/usr/include/readline/readline.h too. So far, no big news I guess.
However:

% locate readline.h
/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/mysql/readline.h
/Developer/SDKs/MacOSX10.4.0.sdk/usr/include/readline/readline.h
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/readline/readline.h

This output looked very interesting, and scanning the readline.h file in
MacOSX10.4u.sdk it gave me the impression that this was dealing with
an up-to-date version of libedit: one that has a compatibility layer
with readline. At least the rl_* functions are declared out there. So
I stepped into those shoes and decided to patch up libxml to use
readline from /Developer/SDKs/MacOSX10.4u.sdk/. Well, ok, because the
configure script seems to plainly ignore whatever you tell it I just
compiled the single file that failed due to a readline dep by hand, and
it was a success, that is after that running make again, everything
finished happily to compile. "make check" was pretty happy too. Running:

% ./.libs/tester --shell test/slashdot.xml
/ >

even gave me an editable prompt with history (!).


Moral of the story: GNU is not Linux. Ehm, no.
- libedit appears to be a 'good enough' replacement for some tools, good
enough to make >=readline-4.1 applications compile
- libedit is in portage
- libedit is supplied with OSX
- libedit is even completer (with readline.h) supplied with Apple's SDKs.
- there unfortunately is no virtual/readline in town, so emerging
libedit doesn't give you readline, while in fact it does.
- assumming we would just lie some more to portage about what it has and
what it doesn't have, we would have to add the readline.h file to
/usr/include and make a package.provided.

I think all is dirty, but not being able to compile libxml because the
testing program -- which a regular user will never use -- uses readline
for its --shell mode which it doesn't even use in make check stinks too.

Besides that I'd like to go a bit broader here for a sec. GPL is
considered to be a virus by many people, and shouldn't this
virtual/readline be a part of portage instead of assuming you use GNU's
readline?

Feel free to tell me I should just wait till we can simply install
readline. (then still I'd like to use libedit I think)


--
Fabian Groffen
eBuild && Porting
Gentoo for Mac OS X
--
gentoo-osx [at] gentoo mailing list


shootingstar at iinet

Aug 20, 2005, 7:28 PM

Post #2 of 2 (489 views)
Permalink
Re: Readline issues [In reply to]

On 20/08/2005, at 11:25 PM, Grobian wrote:
...
>
> Moral of the story: GNU is not Linux. Ehm, no.
> - libedit appears to be a 'good enough' replacement for some tools,
> good enough to make >=readline-4.1 applications compile
> - libedit is in portage
> - libedit is supplied with OSX
> - libedit is even completer (with readline.h) supplied with Apple's
> SDKs.
> - there unfortunately is no virtual/readline in town, so emerging
> libedit doesn't give you readline, while in fact it does.

If libedit really is a complete replacement for readline (they
provide the same functionality and at least compatible symlinks) then
it should be a virtual. Currently the libedit ebuild doesn't install
any compatibility symlinks or the headers, which means that on Gentoo
they aren't really virtuals at the moment.

Making them a virtual is probably a subject for broader discussion
(making libedit install readline compatibility, make libedit/readline
block and make them provide="virtual/readline").

> - assumming we would just lie some more to portage about what it
> has and what it doesn't have, we would have to add the readline.h
> file to /usr/include and make a package.provided.
>

(Because I don't know how this would be done) - where/how would we
add readline.h to /usr/include?

> I think all is dirty, but not being able to compile libxml because
> the testing program -- which a regular user will never use -- uses
> readline for its --shell mode which it doesn't even use in make
> check stinks too.
>

Well making libedit/readline virtuals (if they really are) isn't
dirty at all - it'd be the right solution. Not so sure about moving
readline.h around...

Regards,
Mike


--
gentoo-osx [at] gentoo mailing list

Gentoo osx RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.