harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [classlib][awt] X11 libs
Date Fri, 01 Dec 2006 15:04:39 GMT
Oleg Khaschansky wrote:
>> The requirements on developers may be quite wide. I don't see a 
>> problem that a
>> developer who works on awt has to have X11 installed. It seems to me 
>> quite a
>> sane requirement.
>> We provide *source*. It shall be a pain (actually no pain at all, 
>> Harmony is
>> not the first package in Linux history) for those who create 
>> distributions to
>> arrange all necessary libraries in place.
> 
> You told that we are to do the following (correct me if I am wrong):
> 1. Requre that system on which harmony is built have x11
> 2. Want people build harmony from sources instead of using binary packages
> Then how you imagine headless support in awt, which is intended for
> the configurations without x11 server installed?

There is a difference between X11 *libraries* and X11 *server*. 
Libraries are meant for *client* to enable an application to do X11 
calls. There is no need to have a server installed for application to 
show graphics on a different display where X11 server is running.

Many Linux distributions have X11 libraries and full fledged server 
separated.

> On 12/1/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>> On Thursday 30 November 2006 17:21 Oleg Khaschansky wrote:
>> > > No, Sun links against X11 and ALSA and doesn't use dlopen. It doesn't
>> > > seem to be a problem for anyone. Why can't we?
>> >
>> > Yes, I think we can do this with X11, win32 API, etc. But we need to
>> > have the right set of headers and stublibs to build the wrappers then.
>> > This means that if you don't have X11 you can't build awt.
>>
>> The requirements on developers may be quite wide. I don't see a 
>> problem that a
>> developer who works on awt has to have X11 installed. It seems to me 
>> quite a
>> sane requirement.
>>
>> > > It is dynamic linking. I just don't like it that we have to 
>> *guess* the
>> > > library name. It should be as few such cases as possible. Or we'll 
>> get
>> > > the bug reports like in your URL.
>> >
>> > Yes, ld approach is better from this POW. But transition to it could
>> > be a bit more complicated then adding some heuristics to the existing
>> > "dlopen" code.
>>
>> I didn't mean it should be changed today. I mean that there is no need 
>> to hide
>> dependencies. It is not the way it is done in Linux world. If some 
>> library is
>> needed, it is needed, and it should be installed. Distributions handle it
>> pretty well AFAIK.
>>
>> The way Sun and some other binary packages which are installed on 
>> Linux work
>> is that they try to be universal because they provide *binary* packages.
>> Binary means they don't care about environment, they should work in any
>> installation.
>>
>> We provide *source*. It shall be a pain (actually no pain at all, 
>> Harmony is
>> not the first package in Linux history) for those who create 
>> distributions to
>> arrange all necessary libraries in place.
>>
>> And even for distributions like Gentoo which build everything from 
>> source (I
>> am tempted to write a gentoo ebuild for Harmony from svn , but just don't
>> have time to do this) it is very easy to specify any library in Linux 
>> world
>> as a dependency which should be installed to build the package.
>>
>> I would really like Harmony to be integrated tightly into Linux 
>> current code.
>> All major projects do this, even kde or mozilla, I think we can as 
>> well. If
>> we encounter bugs, we report them upstream just like everyone else 
>> does. Why
>> not?
>>
>> > > I think that distribution integrators may just add opengl package 
>> as a
>> > > dependency to harmony package, so it will be installed if harmony is
>> > > installed.
>> >
>> > The majority of OpenGL calls could be done using ld scheme. The rest
>> > are video driver specific extensions. They should be called using
>> > wgl/glxGetProcAddress anyway.
>>
>> Well, this comes down to using OpenGL on Linux. I am not the expert in 
>> the way
>> OpenGL calls are done on Linux. If they are done through additional 
>> functions
>> found (or not found) in libGL.so, then it is fine. If there is some 
>> way to
>> recognize the extension functions through OpenGL interface, then use 
>> dlsym on
>> them, the scheme looks ok.
>>
>> > On 11/30/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>> > > Oleg Khaschansky wrote:
>> > > >> Sun's Java seem to be bundling some libraries with itself like

>> libzip
>> > > >> and libjpeg. But the rest of the libraries like X11, ALSA, 
>> probably
>> > > >> other are taken from the system.
>> > > >
>> > > > As far as I know, RI uses dlopen approach, at least in some cases,
>> > > > see, e.g. [1].
>> > > >
>> > > >> This means that we
>> > > >> should either bundle in all the required libraries, or use dynamic
>> > > >> linking with the libraries installed in the system.
>> > > >
>> > > > Bundling in X11 and mesa? :)
>> > >
>> > > No, Sun links against X11 and ALSA and doesn't use dlopen. It doesn't
>> > > seem to be a problem for anyone. Why can't we?
>> > >
>> > > > Isn't dlopen/dlsym approach a dynamic linking?
>> > >
>> > > It is dynamic linking. I just don't like it that we have to 
>> *guess* the
>> > > library name. It should be as few such cases as possible. Or we'll 
>> get
>> > > the bug reports like in your URL.
>> > >
>> > > > Again, some API could be missing in some systems (opengl 
>> extensions,
>> > > > for example), what would you suggest to do in this case?
>> > >
>> > > I think that distribution integrators may just add opengl package 
>> as a
>> > > dependency to harmony package, so it will be installed if harmony is
>> > > installed.
>> > >
>> > > > [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5011992
>> > > >
>> > > > On 11/29/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
>> > > >> Oleg Khaschansky wrote:
>> > > >> > I think we should fix this problem for all libraries loaded
with
>> > > >> > dlopen on linux (i.e. for all autogenerated linux native

>> wrappers).
>> > > >> > As far as I recall, this problem already appeared for liblcms

>> and
>> > > >> > libXmu. I'd suggest to wait until we know if we'll have a

>> generator
>> > > >> > of native wrappers in harmony and, probably, fix it instead
of
>> > > >> > making temporary fixes in the autogenerated code.
>> > > >>
>> > > >> Sun's Java seem to be bundling some libraries with itself like

>> libzip
>> > > >> and libjpeg. But the rest of the libraries like X11, ALSA, 
>> probably
>> > > >> other are taken from the system.
>> > > >>
>> > > >> I don't think that replacing dynamic linker on the system with
out
>> > > >> heuristics is the "right way". It is ld.so which should decide

>> which
>> > > >> library from the system should be linked with, be it
>> > > >> /usr/lib/libXext.so.6 or /usr/lib/libasound.so.2. This means 
>> that we
>> > > >> should either bundle in all the required libraries, or use dynamic
>> > > >> linking with the libraries installed in the system.
>> > > >>
>> > > >> It doesn't seem to be a problem for anyone who uses Sun Java on
a
>> > > >> server that it is necessary to install X11 and ALSA libraries.

>> On most
>> > > >> Linux distributions it happens automatically using package
>> > > >> dependencies. So I am -1 for this approach. Instead I think the
>> > > >> wrappers should be changed to link against X11 dynamic libs 
>> directly.
>> > >
>> > > --
>> > > Gregory
>>
>> -- 
>> Gregory
>>
> 


-- 
Gregory


Mime
View raw message