Why does LWL on FreeBSD require Linux lesstif?
c hore
Is it just a too old version...lesstif-0.91.8 on
http://www.freebsd.org/ports vs. the 0.92.32 or higher
required by LWL?
Or is there a deeper reason that will always hold
even if the FreeBSD lesstif ever gets updated?
Is there a general rule that says that when running
a Linux executable in FreeBSD under Linux compatibility
mode, if the executable calls a library, the library
has to be the Linux version of the library and not
the FreeBSD version of the library?
(What is the difference between the Linux and FreeBSD
versions of a library?)
Espen Vestre
> Out of curiosity, why cannot the FreeBSD lesstif be used?
> Is it just a too old version...lesstif-0.91.8 on
> http://www.freebsd.org/ports vs. the 0.92.32 or higher
> required by LWL?
does lesstif work o.k. for you at all?
I had to switch to OpenMotif.
--
(espen)
Henrik Motakef
> Is there a general rule that says that when running
> a Linux executable in FreeBSD under Linux compatibility
> mode, if the executable calls a library, the library
> has to be the Linux version of the library and not
> the FreeBSD version of the library?
Yes. You cannot mix them.
Greg Menke
> > Out of curiosity, why cannot the FreeBSD lesstif be used?
> > Is it just a too old version...lesstif-0.91.8 on
> > http://www.freebsd.org/ports vs. the 0.92.32 or higher
> > required by LWL?
>
> does lesstif work o.k. for you at all?
> I had to switch to OpenMotif.
I found 4.1 and 4.2 extremely sensitive to the version of lesstif.
The LW gui was quite unstable until I compiled and installed the exact
version of lesstif as suggested by the documentation. Since then, its
been fine.
Gregm
Joel Ray Holveck
> a Linux executable in FreeBSD under Linux compatibility
> mode, if the executable calls a library, the library
> has to be the Linux version of the library and not
> the FreeBSD version of the library?
That's correct. Same also goes for the SVR4 and iBCS2 (SCO) emulation
modes.
> (What is the difference between the Linux and FreeBSD
> versions of a library?)
The operating system calls used by the two OS's are different. They
are differently numbered, have different structure layouts, and in
some cases, have different semantics.
joelh
Erik Naggum
| The operating system calls used by the two OS's are different. They are
| differently numbered, have different structure layouts, and in some cases,
| have different semantics.
But the glibc calls should still be the same, protecting the user code from
having to even know those system call numbers or structures.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Marc Spitzer
> * Joel Ray Holveck
> | The operating system calls used by the two OS's are different. They are
> | differently numbered, have different structure layouts, and in some cases,
> | have different semantics.
>
> But the glibc calls should still be the same, protecting the user code from
> having to even know those system call numbers or structures.
>
The issue, at least, that freebsd and linux have different calling
conventions for function calls. The url is:
http://www.freebsd.org/docs/en_US.ISO8859-1/books/developers-handbook/
x86-system-calls.html
for the details. So you must use kinux compiled libs for linux apps,
lispworks is linux app but acl supports freebsd nativly. Also freebsd
does not use glibc it has its own libc so there could be issues there
as well.
marc
Erik Naggum
| Also freebsd does not use glibc it has its own libc so there could be issues
| there as well.
Ah. A crucial piece of evidence. (What a waste, though.)
Johannes Grødem
>> Also freebsd does not use glibc it has its own libc so there could
>> be issues there as well.
> Ah. A crucial piece of evidence. (What a waste, though.)
It's because they prefer BSD-licensed software, which glibc is not.
--
johs
Nils Kassube
>>> Also freebsd does not use glibc it has its own libc so there could
>>> be issues there as well.
>> Ah. A crucial piece of evidence. (What a waste, though.)
> It's because they prefer BSD-licensed software, which glibc is not.
And if you've seen the glibc source code, you'd probably want to use
something different, too.
Joel Ray Holveck
>>> be issues there as well.
>> Ah. A crucial piece of evidence. (What a waste, though.)
> It's because they prefer BSD-licensed software, which glibc is not.
I don't think there was ever any question of license. BSD always had
a perfectly good libc, since it first was distributed in 1977/78.
(Okay, "perfectly good" doesn't describe 1BSD's libc, but...) There
was never a decision to not move to glibc, because of license or
anything else.
joelh
Joel Ray Holveck
>>> differently numbered, have different structure layouts, and in some cases,
>>> have different semantics.
>> But the glibc calls should still be the same, protecting the user code from
>> having to even know those system call numbers or structures.
> The issue, at least, that freebsd and linux have different calling
> conventions for function calls. The url is:
To be clear, the *function* call convention is the same; it's the
*system* call convention that's different.
> http://www.freebsd.org/docs/en_US.ISO8859-1/books/developers-handbook/
> x86-system-calls.html
(But I guess you knew that.)
> Also freebsd does not use glibc it has its own libc so there could
> be issues there as well.
When running a Linux app, it uses glibc.
That's one other point of Linux compat: you link in the Linux versions
of libraries, which may have different semantics than the FreeBSD
versions.
joelh
Joel Ray Holveck
>> differently numbered, have different structure layouts, and in some cases,
>> have different semantics.
> But the glibc calls should still be the same, protecting the user code from
> having to even know those system call numbers
True.
> or structures.
False.
You may not have to know the system call numbers, but you do still
need to know the value of O_CREAT, the layout of a struct sigaction,
the CD-ROM's struct cd_sub_channel_info, or the ioctl number of
SNDCTL_DSP_POST. A Linux program may try to get the IP address of
eth0, but FreeBSD uses a different scheme for naming its interfaces.
Linux programs expect the semantics of F_SETOWN on pipes to be
different than they are in BSD. (All these are examples of actual
differences between FreeBSD and Linux.)
That's not even starting on the idea that a good bit of commercial
software (which is what you usually need linux compatibility for) is
statically linked anyway.
There's a lot of kernel knowledge that goes into the average program.
FreeBSD isn't Linux, and doesn't want to be.
Cheers,
joelh
Marc Spitzer
>>>> The operating system calls used by the two OS's are different. They are
>>>> differently numbered, have different structure layouts, and in some cases,
>>>> have different semantics.
>>> But the glibc calls should still be the same, protecting the user code from
>>> having to even know those system call numbers or structures.
>> The issue, at least, that freebsd and linux have different calling
>> conventions for function calls. The url is:
>
> To be clear, the *function* call convention is the same; it's the
> *system* call convention that's different.
>
>> http://www.freebsd.org/docs/en_US.ISO8859-1/books/developers-handbook/
>> x86-system-calls.html
>
> (But I guess you knew that.)
actualy I had them confused, thanks for straighting that out.
marc
Kaz Kylheku
>| The operating system calls used by the two OS's are different. They are
>| differently numbered, have different structure layouts, and in some cases,
>| have different semantics.
>
> But the glibc calls should still be the same, protecting the user code from
> having to even know those system call numbers or structures.
Note that glibc doesn't even keep these structures the same from one revision
to the next. When you upgrade your GNU/Linux distro, the reason your old
compiled programs stay working is that ELF symbol versioning is used by glibc
to provide a binary compatible interface to them; glibc in effect emulates
older versions of itself.
c hore
Contrary to what Xanalys LWL Installation Guide suggests
("Lesstif 0.92.32 or higher"), I could not get LWL Pro 4.2
to work on FreeBSD 4.4 using the latest Linux lesstif, 0.93.36.
The first error from LWL was:
Error: Could not register handle for external module
X-UTILITIES::CAPIX11: libXm.so.1: cannot open shared
object file: No such file or directory.
Then when I did the evil (I understand) kludge of setting
environment variable LD_LIBRARY_PATH to /usr/X11R6/lib
the error changed to:
Error: Could not register handle for external module
X-UTILITIES::CAPIX11: /lib/libc.so.6: version
`GLIBC_2.1.3' not found (required by /usr/X11R6/lib/libXm.so.1)
Then I did not know what to do anymore, so with the help of
find and xargs, I painstakingly removed all the files that
were extracted from lesstif-0.93.36.cpio (which came
from the downloaded lesstif-0.93.36.rpm file via rpm2cpio).
Then I installed lesstif-0.92.32 which is on the
Xanalys CD as a .rpm file. Same rigmarole which I had to
guess/research since there is no LWL documentation on exactly
WTH to do with this .rpm file --- rpm2cpio followed by
cpio -idv while at / .
The first error from LWL was the same as the first error
above. Then I did the evil LD_LIBRARY_PATH kludge,
and then LWL finally worked.
But before that I think I also had to chmod 755 three directories
that cpio -idv extracted from the lesstif-0.92.32.cpio file.
For some reason, they had 700 mode upon extraction.
Also I had to chown root:wheel what cpio extracted since they
were not root:wheel even though I was su'ed to root.
In summary, LWL 4.2 on FreeBSD 4.4 did not work using the
latest lesstif, 0.93.36. I had to use the lesstif 0.92.32
on Xanalys CD.
I wish there were a better out-of-box user experience
for LWL on FreeBSD. I wish Xanalys would at least put
some unofficial notes out on their web site for those
installing on FreeBSD. The one note that they have in
their "Knowledgebase" is dated, insufficient and
potentially (and in my case, actually) misleading.
It had me barking up the wrong tree putting symbolic
links in /compat/linux which turned out to not be
necessary.
Or would putting the symbolic links in /compat/linux
remove the need for the LD_LIBRARY_PATH kludge?
Friedrich Dominicus
>
> The first error from LWL was:
> Error: Could not register handle for external module
> X-UTILITIES::CAPIX11: libXm.so.1: cannot open shared
> object file: No such file or directory.
You might check out the
$LispWorks/lib/4-2-0-0/config/use-motif-library
file. I have change it that it prefers to search for libXm.so.2..
BTW I would use openmotif anyway, there seems to be a problem with
(older?) lesstif, while click right the context menus get hang in the
upper left corner ...
> Then when I did the evil (I understand) kludge of setting
> environment variable LD_LIBRARY_PATH to /usr/X11R6/lib
> the error changed to:
> Error: Could not register handle for external module
> X-UTILITIES::CAPIX11: /lib/libc.so.6: version
> `GLIBC_2.1.3' not found (required by /usr/X11R6/lib/libXm.so.1)
see use-motif-library
(:detect-version (("/usr/X11R6/lib/libXm.so.1" 1)
is probably the "right" way of choosing where the libXm stuff is kept.
>
> Then I installed lesstif-0.92.32 which is on the
> Xanalys CD as a .rpm file. Same rigmarole which I had to
> guess/research since there is no LWL documentation on exactly
> WTH to do with this .rpm file --- rpm2cpio followed by
> cpio -idv while at / .
I would thing that is a bug. You should use rpm -i or the like to
install .rpm packages. If that does not work you can fall back to
generic tar.gz files.
> I wish there were a better out-of-box user experience
> for LWL on FreeBSD. I wish Xanalys would at least put
> some unofficial notes out on their web site for those
> installing on FreeBSD. The one note that they have in
> their "Knowledgebase" is dated, insufficient and
> potentially (and in my case, actually) misleading.
> It had me barking up the wrong tree putting symbolic
> links in /compat/linux which turned out to not be
> necessary.
As I understand LispWorks is not a supported product under FreeBSD. So
you won't probably have much luck till you can convince them that
there is a market for LispWorks on FreeBSD too.
>
> Or would putting the symbolic links in /compat/linux
> remove the need for the LD_LIBRARY_PATH kludge?
see above.
Regard
Friedrich
Marc Spitzer
> As I understand LispWorks is not a supported product under FreeBSD. So
> you won't probably have much luck till you can convince them that
> there is a market for LispWorks on FreeBSD too.
Well I would buy it for freebsd, hell I would probably buy it
for linux iff it was supported when I told them I was running
freebsd. And it would be real cool if the freebsd native port,
if it ever came into existance, was licenced in the same manner
as linux/windows.
marc
ps before I get accused of asking for something for nothing, I would
be happy to pay for the product and maintenence on it for the simple
reason that it is the only way I have a hope at having a commerical
product to use. If there was a way to give some money to cmucl I
would do it, the last time I went to the website I did not see
anything like that though.
marc
>
> Regard
> Friedrich
>
Daniel Barlow
> product to use. If there was a way to give some money to cmucl I
> would do it, the last time I went to the website I did not see
> anything like that though.
For the record,
There is no formal commercial support structure for
CMUCL. However, some of the CMUCL developers may be available on
an individual basis for consulting, for example to implement new
features or help in porting a particular application. Please email
the cmucl-imp list with details of your requirements.
(from http://www.cons.org/cmucl/support.html). So, although there are
no "off-the-peg" support packages, you can always negotiate directly
with the developers for something that fits your needs.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Marc Spitzer
> ma...@oscar.eng.cv.net (Marc Spitzer) writes:
>
>> product to use. If there was a way to give some money to cmucl I
>> would do it, the last time I went to the website I did not see
>> anything like that though.
>
> For the record,
>
> There is no formal commercial support structure for
> CMUCL. However, some of the CMUCL developers may be available on
> an individual basis for consulting, for example to implement new
> features or help in porting a particular application. Please email
> the cmucl-imp list with details of your requirements.
>
> (from http://www.cons.org/cmucl/support.html). So, although there are
> no "off-the-peg" support packages, you can always negotiate directly
> with the developers for something that fits your needs.
>
I was thinking about around $200 for project/personal needs(books,
beer, DVDs or something else). That is not a drop in the bucket as
far as consulting goes. And I would like to spread it out a bit.
Perhaps there could be a link off of cmucl's web page for each core
developer with a wish list of things they would like to get from
amazon. I will go ask on cmucl-help also, better place.
marc
c hore
> As I understand LispWorks is not a supported product under FreeBSD. So
> you won't probably have much luck till you can convince them that
> there is a market for LispWorks on FreeBSD too.
I don't know if I could convince Xanalys, but maybe Franz could?
Allegro Common Lisp officially supports FreeBSD.
(Is that a native version or via Linux compatibility?)
Isn't that free market research for Xanalys?
On the other hand, maybe Franz has significantly greater
market share, budget, staff, and/or experience such that
they can support more platforms, I don't know.
I guess there is also the issue of whether FreeBSD support means
a native version, or just documenting and providing tech support
on the use of the Linux version via Linux compatibility.
I, for one, would be happy with even just the latter...or
might even prefer the latter since it gives you the flexibility
to install and use on both Linux and FreeBSD.
Marc Spitzer
> Friedrich Dominicus wrote:
>> As I understand LispWorks is not a supported product under FreeBSD. So
>> you won't probably have much luck till you can convince them that
>> there is a market for LispWorks on FreeBSD too.
>
> I don't know if I could convince Xanalys, but maybe Franz could?
> Allegro Common Lisp officially supports FreeBSD.
> (Is that a native version or via Linux compatibility?)
> Isn't that free market research for Xanalys?
>
> On the other hand, maybe Franz has significantly greater
> market share, budget, staff, and/or experience such that
> they can support more platforms, I don't know.
franz is a native port
marc