Re: [Pharo-project] External web browser

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] External web browser

laza
Hilaire,

on Linux the ExternalWebBrowser package, as it is, depends on a helper program (e.g. xdg-open) to open a url in the default browser.

The helper program is executed using the system() function of the standard C library. This is defined in

ExternalWebBrowser>>system: string
"system() executes a command specified in string by calling /bin/sh -c
string, and returns after the command has been completed."
<apicall: short 'system' (char*) module: 'c'>
^self externalCallFailed

The problem is, that the VM is unable to find that 'c' module/library as you can see when you evaluate

ExternalWebBrowserUnix isCLibAvailable

The VM is actively looking for a library file before it will use the dynamic linker to actually load it. The VM uses permutations of well known library locations (e.g. /lib) with library pre- (e.g. lib) and postfixes (e.g. .so) to find the file.
So for example it will look for /lib/libc.so (among many others see [1] on a related matter)

But even back at the time I started the ExternalWebBrowser package, the Linux distributions that I used (Debian, Ubuntu) didn't provide such a file, but /lib/libc.so.6. And the VM would not look for such a file.
So to make it work I used a hack that Andreas Raab used with his OpenGL package to change the module name of the FFI definitions on the fly.
In isCLibAvailable  I try to use the generic module name 'c' and if that fails I try it again with the specific module name 'libc.so.6'.

This (hack) worked as long as there was such a file. Now it seems that on newer Linux distributions even this file disappeared and it all depends on the dynamic linker to find the right shared library file.
One could extend the list of module names to try by '/lib/i386-linux-gnu/libc.so.6' as on my system, but that would most probably not work with 64bit systems and so on.

A better solution would be to adapt the way tries to find/load shared libraries.
In the special case of handling URLs by external programs, I think Bert Freudenberg suggested that the/a VM/VM-Module should provide such a functionality.

Alex
 
[1] http://forum.world.st/OpenGL-in-4-1-or-later-td3794639.html#a4214041

2011/12/21 Hilaire Fernandes <[hidden email]>:
> Hello,
>
> What is the status of external web browser use.
> Last time I checked several months ago I can't use it with Linux.
> Anyone using it successfully recently?
>
> Thanks
>
> Hilaire
>
> --
> Dr. Geo -- http://www.drgeo.eu
>
>



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] External web browser

Hilaire Fernandes
Alex,

Thanks for the info

Hilaire

Le 22/12/2011 11:59, Alexander Lazarević a écrit :

> Hilaire,
>
> on Linux the ExternalWebBrowser package, as it is, depends on a helper
> program (e.g. xdg-open) to open a url in the default browser.
>
> The helper program is executed using the system() function of the
> standard C library. This is defined in
>
> ExternalWebBrowser>>*system:* string
> "system() executes a command specified in string by calling /bin/sh -c
> string, and returns after the command has been completed."
> <*apicall:* short 'system' (char*) *module:* 'c'>
> ^self externalCallFailed
>
> The problem is, that the VM is unable to find that 'c' module/library as
> you can see when you evaluate
>
> ExternalWebBrowserUnix isCLibAvailable
>
> The VM is actively looking for a library file before it will use the
> dynamic linker to actually load it. The VM uses permutations of well
> known library locations (e.g. /lib) with library pre- (e.g. lib) and
> postfixes (e.g. .so) to find the file.
> So for example it will look for /lib/libc.so(among many others see [1]
> on a related matter)
>
> But even back at the time I started the ExternalWebBrowser package, the
> Linux distributions that I used (Debian, Ubuntu) didn't provide such a
> file, but /lib/libc.so.6. And the VM would not look for such a file.
> So to make it work I used a hack that Andreas Raab used with his OpenGL
> package to change the module name of the FFI definitions on the fly.
> In isCLibAvailable  I try to use the generic module name 'c' and if that
> fails I try it again with the specific module name 'libc.so.6'.
>
> This (hack) worked as long as there was such a file. Now it seems that
> on newer Linux distributions even this file disappeared and it all
> depends on the dynamic linker to find the right shared library file.
> One could extend the list of module names to try by
> '/lib/i386-linux-gnu/libc.so.6' as on my system, but that would most
> probably not work with 64bit systems and so on.
>
> A better solution would be to adapt the way tries to find/load shared
> libraries.
> In the special case of handling URLs by external programs, I think Bert
> Freudenberg suggested that the/a VM/VM-Module should provide such a
> functionality.
>
> Alex
>  
> [1] http://forum.world.st/OpenGL-in-4-1-or-later-td3794639.html#a4214041
>
> 2011/12/21 Hilaire Fernandes <[hidden email]
> <mailto:[hidden email]>>:
>> Hello,
>>
>> What is the status of external web browser use.
>> Last time I checked several months ago I can't use it with Linux.
>> Anyone using it successfully recently?
>>
>> Thanks
>>
>> Hilaire
>>
>> --
>> Dr. Geo -- http://www.drgeo.eu
>>
>>
>
>
>
>


--
Dr. Geo -- http://www.drgeo.eu