"libc.so" is somewhat of the standard system default on all things
Unix, with Darwin being different. The idea is to have libc.so be a
symbolic link to the real thing. Loading with an explicit version
number is a bad idea, but then, Unix is full of bad ideas.
What I mean to say is: There is no
No. libc.so.6 just for Linux, I think it means the 6th big revision
(with incompatible API changes) of the GNU C Library.
On Solaris (I have some Solaris 10 (both SPARC and x86) boxes),
there's no libc.so.6 but libc.so.1:
[EMAIL PROTECTED]:/usr/lib$ ls -l libc.so*
lrwxrwxrwx 1 root
在 2008-10-1，15:24， Leslie P. Polzer 写道：
So the libc6 statement would work for 99% of UNIX users
Unix or Linux? What statement would we need on Solaris/ *BSD?
I don't have boxes to check on, but I suppose libc6.so is pretty
safe for UNIX.
No. libc.so.6 just for Linux, I think it means the
>> So the libc6 statement would work for 99% of UNIX users
>
> Unix or Linux? What statement would we need on Solaris/ *BSD?
I don't have boxes to check on, but I suppose libc6.so is pretty
safe for UNIX.
>> whereas the current situation works for 0% of CLISP users.
>
> Well, if it really didn'
On Tue, Sep 30, 2008 at 07:49:54PM +0200, Erik Huelsmann wrote:
> On Tue, Sep 30, 2008 at 10:22 AM, Leslie P. Polzer
> <[EMAIL PROTECTED]> wrote:
> >
> >> The reason it's not there yet is that I'm unaware of a good way to
> >> detect which libc version is installed on a system. Or would it always
>
On Tue, Sep 30, 2008 at 10:22 AM, Leslie P. Polzer
<[EMAIL PROTECTED]> wrote:
>
>> The reason it's not there yet is that I'm unaware of a good way to
>> detect which libc version is installed on a system. Or would it always
>> be libc.so.6?
>
> I suppose libc5 is outdated enough to forget about it
> The reason it's not there yet is that I'm unaware of a good way to
> detect which libc version is installed on a system. Or would it always
> be libc.so.6?
I suppose libc5 is outdated enough to forget about it
and a libc7 is still far away. :)
So the libc6 statement would work for 99% of UNIX
On Sun, Sep 28, 2008 at 1:54 AM, Zach Beane <[EMAIL PROTECTED]> wrote:
> On Sun, Sep 28, 2008 at 12:37:37AM +0200, Leslie P. Polzer wrote:
>>
>> > Does it work if you put this:
>> >
>> > (ffi:default-foreign-language :stdc)
>> > (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc
On Sun, Sep 28, 2008 at 12:37:37AM +0200, Leslie P. Polzer wrote:
>
> > Does it work if you put this:
> >
> > (ffi:default-foreign-language :stdc)
> > (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is
> >
> > into your ~/.clisprc ?
>
> If this doesn't help, try adding
>
>
> Does it work if you put this:
>
> (ffi:default-foreign-language :stdc)
> (ffi:default-foreign-library "libc.so.6") ;; or whatever your libc is
>
> into your ~/.clisprc ?
If this doesn't help, try adding
#+unix (:library "libc.so.6") ;; or darwin if you need it
in backend/clisp.lisp, rig
> When compiling usocket 0.3.7 on CLISP 2.46, I get this error:
>
> ;; Loading file
> /Users/xach/src/zs3-test/source/usocket-0.3.7/backend/clisp.fas ...
> ** - Continuable Error
> FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not
> exist
>
> Any ideas?
Does it work if
When compiling usocket 0.3.7 on CLISP 2.46, I get this error:
;; Loading file
/Users/xach/src/zs3-test/source/usocket-0.3.7/backend/clisp.fas ...
** - Continuable Error
FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not
exist
Any ideas?
Zach
___
12 matches
Mail list logo
