REBOL/View - Ubuntu Linux - opening browser

[Nicholas]

I have installed REBOL/View on a 64bit laptop running Ubuntu and if I click on any of the boxes that should bring up the browser (the documents tab in help for example) nothing happens. Any tips on how I fix this. I also tried starting View from the command line terminal but this made no difference.

Apologies if this is answered somewhere else but I did a search and could not find an answer.

[Anton]

Hi,

You could try to set 'BROWSE to a mezzanine function like this:

browse: func [url /only][call reform ["path to browser command" rejoin [{"} url {"}]]]

(substituting your actual path).

And when you have it working, you can put it in your user.r file.

[Nicholas]

Hi Anton,

Thanks very much. It all worked

It took me a while to find and edit the user.r file but that's because I am new to Linux as well as Rebol. Now to try and learn the next step.

[tim042849]

I can't get either rebol/core or rebol/view to run on my ubuntu 7.04 64-bit.
I get a "No such file or directory error message" when I attempt to
execute the binary. Anyone know what that is all about?
thanks
tim

[bouba]

the rebol executable is probably not in your PATH.
Have you tried :
./rebol

in the directory where the binary is?

[tim042849]

It *is* in the path, I've tried both /usr/bin and /usr/local/bin and I have tried it as ./rebol as well. Same error message
furthermore, `which' finds it.

[bouba]

When you use the command file on your rebol binary, does it recognize it as an executable?

[tim042849]

Here's the solution (copy of message I sent to the rebol mailing list)
***********************************************************
When I attempted to install the 32-bit rebol binary which was compiled for
32-bit ubuntu on ubuntu 7.04, execution of the binary returned only a
message: "No such file or directory". I believe that message came from
rebol itself, but that is only speculation on my part.

Running ldd was unsuccessful even tho' `file rebol' did report that is was
a 32-bit executable.

Running `ldd rebol' on slackware returned this information:
libm.so.6 => /lib/libm.so.6 (0x4002c000)
        libc.so.6 => /lib/libc.so.6 (0x4004e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libm.so.6 and libc.so.6 were present on the ubuntu machine, but
ld-linux.so.2 - the dynamic loader - was not. Ubuntu has obsoleted it.
Installing a 32-bit loader was unsuccessful.

I'm an old (in more ways than one) "C" programmer with some experience working
with dlls on windows, which are the equivalent of linux shared object
libraries. I suspected that the paths to the shared objects were hard-coded
in the binary and after some inspection I did find them.

I made a copy of the rebol binary on opened with vim using the -b switch,
thus putting vim in binary mode.
--------------------------------------------------------------------------------------------
NOTE: There is a wonderful windows shareware application called ztreewin,
and one of it's tools is a hex editor - actually it is a modern clone of
xtreegold.
-------------------------------------------------------------------------------------------
I then edited the paths to the binaries as follows:
libm.so.6 => l1bm.so.6
libc.so.6 => l1bc.so.6
ld-linux.so.2 => ld-l1nux.so.2
and made copies of the shared objects with those name changes, ported all to
the ubuntu machine and I have rebol running.
------------------------------------------------------------------------
Now for a bit of a rant:
RT likes to advertise rebol's portability - RT: put your money where your
mouth is and provide a build that is compatible with 64-bit ubuntu, 'cuz I
suspect that there is going to be a lot of those distros being installed in
the future.
_and_ get rebol in the repositories!!!
-------- end of rant------------------------------
In the next few days, I will be putting this ubuntu machine to work with rebol
scripts. If the "hacked" rebol shows no problems, then the solution could be
so simple as to recompile the standard linux build with different names for
the shared objects and their paths, and include those renamed objects as part
of the package.

[Gabriele]

Tim, if that's the case, you can also just set the LD_LIBRARY_PATH variable to a dir with your libraries, without having to modify the executable.

About building REBOL (2) for 64 bit linux... if there are enough requests, I'm sure that will be done. However, the big problem with linux is that to avoid problems you basically have to make a specific build for each distribution... considering the number of them, this is not doable.

REBOL 3 will of course solve this problem once and forall, because anybody will be able to create a build.

[tim042849]

Tim, if that's the case, you can also just set the LD_LIBRARY_PATH variable to a dir with your libraries, without having to modify the executable.

But wouldn't that cause problems with other apps?

About building REBOL (2) for 64 bit linux... if there are enough requests, I'm sure that will be done. However, the big problem with linux is that to avoid problems you basically have to make a specific build for each distribution... considering the number of them, this is not doable.

REBOL 3 will of course solve this problem once and forall, because anybody will be able to create a build.

Looking forward to it!

[Gabriele]

Tim, if that's the case, you can also just set the LD_LIBRARY_PATH variable to a dir with your libraries, without having to modify the executable.

But wouldn't that cause problems with other apps?

No, because you can set it for REBOL only, ie.

Code:

> LD_LIBRARY_PATH=~/rebol-libs/ /usr/local/bin/rebol

The variable is valid only for the next program executed unless you export it (assuming you're using bash). Example:

Code:

giesse@batou:~$ env | grep VAR
giesse@batou:~$ VAR=something env | grep VAR
VAR=something
giesse@batou:~$ env | grep VAR

[tim042849]

So - I would
1)create a directory at /usr/local/bin/rebol
2)install the rebol binary and the 32-bit shared objects
   in that directory
3)And place
   export LD_LIBRARY_PATH=~/rebol-libs/ /usr/local/bin/rebol
   in .bashrc
am I correct?
OR
1)Place the shared objects with unchanged names at
   ~/rebol-libs (user created directory)
2)and then LD_LIBRARY_PATH points to ~/rebol-libs when
   rebol is executing?
   But remember, the paths to the shared objects is hard-coded
   in the binary.
Anyway, will try later.
------
I didn't know about the second parameter
thanks
tim

[Gabriele]

So - I would
1)create a directory at /usr/local/bin/rebol
2)install the rebol binary and the 32-bit shared objects
   in that directory
3)And place
   export LD_LIBRARY_PATH=~/rebol-libs/ /usr/local/bin/rebol
   in .bashrc

No, that would launch REBOL in your .bashrc file, and export the new library path to all other programs.

1)Place the shared objects with unchanged names at
   ~/rebol-libs (user created directory)
2)and then LD_LIBRARY_PATH points to ~/rebol-libs when
   rebol is executing?

Exactly. Does not need to be in your home dir, that was just an example. You can then create a wrapper script to launch REBOL, that sets the var and launches it.

   But remember, the paths to the shared objects is hard-coded
   in the binary.

I don't know if that's normal or not, however it may mean that the system one get precedence... in that case setting the lib path will not work.