A new definition of libraries (was: Linux Installation)

[Andre Garzia]

If I may throw a couple cents at the conversation so that things  
become more clear it might help everyone here.

The problem about linux family of operating systems is the library  
organization of each distro. When you make a standalone, Rev glues  
stack and engine togheter. The engine is linked against many shared  
libraries. This is true for all systems. Shared libraries are what  
makes modern systems "easy" to develop and also makes our final code  
smaller since code shared by many applications can be called from  
those shared libraries instead of being added to the final executable  
by static linking.

The thing about linux is that it is so customizable that each distro  
(and even many users sharing using the same distro but with different  
customizations) organized their shared libraries in a different way.  
Some library that might be placed in one place in a system might be  
on a different place on other or even missing. The dynamic loader  
that is responsible for managing this stuff is not magical and can't  
cope with all kinds of possibilities. Even as libraries changes,  
users are forced to mantain multiple versions of the library  
installed so that updating a library will not break any shared code.  
It's common to find more than one instance of a given library,  
specially if the library had some heavy change in the last revision.  
Thats why linux is a "mess".

Now let us get back to Rev. I've encountered two problems with linux  
and Rev regarding shared libraries. One is that some older versions  
of linux come with some outdated glibc (libC) like version X when rev  
is linked against version Y. That is to say that you must correct the  
location or version of such library for Rev to run. This is a problem  
that many CGI users faced. For example some servers of Dreamhost are  
running on outdated libC. As for the GUI part. I think Rev links  
against GTK and friends. So you must have GTK (and GDK and the rest  
of the dependency tree) for it to run. A simple "ldd" command will  
display to you which libraries the version of Rev you have are linked  
against (this is for linux, mac os x users should use otool instead  
of ldd and windows, I don't have a clue). After seeing which  
libraries Rev is calling, make sure you have them all installed and  
in the path rev is looking for. After that Rev should run fine. If  
you're running a professional distro such as Fedora, running rev  
might be as simple as double clicking. The procedure displayed here  
is for troubleshooting a non running rev and not for all users.

Andre

PS: did it help? I don't use linux for ages...

On Jun 10, 2006, at 5:55 PM, Dan Shafer wrote:

> Let me be clear up front that I am far from a Linux expert. I *am*  
> a KDE
> user. And the last post here brought me to a point of remembering  
> what a
> colleague of mine who IS a serious Linux guy told me a couple of  
> weeks ago
> in another context. Direct quotation:
>
> "Linux is the only OS for which there are many windowing  
> environments. If
> Windows had multiple UIs, you'd have the same problem there. You  
> don't. So
> it's not really proper to discuss 'Linux compatibility.' The issue  
> is KDE
> compatibility or Gnome compatibility. Within those constraints, an
> application can be said to run on a particular windowing  
> environment or on
> multiple windowing environments. But anyone who tells you they have  
> an app
> that runs on every version of Linux has a very simplistic app or a  
> very
> simplistic understanding of what constitutes Linux."
>
> That makes sense to me. Maybe it doesn't help clarify this  
> discussion, but
> it makes sense to me.
>
> On 6/10/06, Richard Gaskin <ambassador at fourthworld.com> wrote:
>>
>> Bob Warren wrote:
>>
>> > What I am trying to ask is this:
>> >
>> > I produce a "Hello world" standalone application in Rev Linux.  
>> Will it
>> > run without problems on every known Linux?
>>
>> "Linux"?  Probably, but that means no GUI.
>>
>> If by "every" you mean every window manager that sits on top of  
>> Linux,
>> that's a maybe for Rev just as it is for RB and many others.
>>
>> The problem here is the casual disregard for consistency among the  
>> many
>> unrelated window managers.  When all but one of them either go  
>> away or
>> become relegated to specialized uses, not only with GUI app makers  
>> have
>> a much better time writing for it, but the Linux desktop market  
>> will at
>> last grow to the levels the kernel deserves.
>>
>> Until then, the mine's-more-precious-than-yours approach to making  
>> the
>> unnecessary plethora of window managers that sit on top of Linux is
>> hurting developers' productivity as much as it's hurting their own
>> evangelism of Linux.
>>
>> --
>>   Richard Gaskin
>>   Managing Editor, revJournal
>>   _______________________________________________________
>>   Rev tips, tutorials and more: http://www.revJournal.com
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
>
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Shafer, Information Product Consultant and Author
> http://www.shafermedia.com
> Get my book, "Revolution: Software at the Speed of Thought"
>> From http://www.shafermediastore.com/tech_main.html
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution