You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/11/29 11:47:54 UTC
[classlib][awt] X11 libs
Just pulling out Mark's recommendation and changing the subject to get
the right people's attention.
Mark Hindess wrote:
> On 29 November 2006 at 9:24, Tim Ellison <t....@gmail.com> wrote:
>> Mark Hindess wrote:
>>> Actually it's another .so problem. This time does actually give the
>>> meaningful error:
>>>
>>> Caused by: java.lang.Throwable:
>>> java.lang.UnsatisfiedLinkError: Cannot load libXtst.so library
<snip>
>>> I've installed the development package on this machine so the problem
>>> should disappear, but this really should be fixed in the source.
>> Meaning? it should try to load the versioned names too?
>
> It should try to load versioned names first. We know classlib works
> with X11R6 but I don't know if anyone has tested it with X11R4/5/7?
> We should try to load libXtst.so.6 (and libXtst.so.7 if that has been
> tested?) and then libXtst.so. It is clear from bug reports that (at
> least) Debian and Ubuntu don't consider the lack of unversioned .so
> files in runtime packages to be an error. So it is down to us to make
> it work for the common case - i.e. only versioned .so file present.
Sounds reasonable to me -- unless there are any objections I'll make the
change.
Anyone tested with R4/5/7 ? Do we expect them to work?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][awt] X11 libs
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Geir Magnusson Jr. wrote:
>>
>>
>> Gregory Shimansky wrote:
>>> Alexey Petrenko wrote:
>>
>>>> Don't you need to specify exact version of library you depend on?
>>>
>>> It is up to distributions to care about the exact version of
>>> libraries that they provide. When they build and test harmony with
>>> these libraries the exact version will be recorded in the package.
>>
>> Hang on - what do you mean "when they build and test harmony?" I'm
>> sure that some distros may do that - get the TCK license from Sun and
>> test - I'm not convinced it will be many. It will be up to us, at
>> least at first, to start doing certified builds for a matrix of
>> precise versions and distros. "harmony for linux" isn't going to cut
>> the mustard.
>
> I don't think distros will do any TCK testing. They will assume that any
> build passes TCK as long as we claim that we did pass it.
They can't call it Java then, nor claim it conformant. Only a binary can
be tested conformant. The source has no "conformance-ness"
> It is quite
> different, Java conformance (in the sense of passing TCK) or just
> another Linux Java implementation along with kaffe and gcj with
> classpath. Do kaffe and gcj have TCK certification on all distributions,
> is it really needed?
If you want to call it Java, yes.
>
> Under testing I meant that distributions will test compatibility between
> Harmony and the media libraries versions which are used in distribution
> version.
I can't imagine to what avail if they want Java.
geir
>
Re: [classlib][awt] X11 libs
Posted by Gregory Shimansky <gs...@gmail.com>.
Geir Magnusson Jr. wrote:
>
>
> Gregory Shimansky wrote:
>> Alexey Petrenko wrote:
>
>>> Don't you need to specify exact version of library you depend on?
>>
>> It is up to distributions to care about the exact version of libraries
>> that they provide. When they build and test harmony with these
>> libraries the exact version will be recorded in the package.
>
> Hang on - what do you mean "when they build and test harmony?" I'm sure
> that some distros may do that - get the TCK license from Sun and test -
> I'm not convinced it will be many. It will be up to us, at least at
> first, to start doing certified builds for a matrix of precise versions
> and distros. "harmony for linux" isn't going to cut the mustard.
I don't think distros will do any TCK testing. They will assume that any
build passes TCK as long as we claim that we did pass it. It is quite
different, Java conformance (in the sense of passing TCK) or just
another Linux Java implementation along with kaffe and gcj with
classpath. Do kaffe and gcj have TCK certification on all distributions,
is it really needed?
Under testing I meant that distributions will test compatibility between
Harmony and the media libraries versions which are used in distribution
version.
--
Gregory
Re: [classlib][awt] X11 libs
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Alexey Petrenko wrote:
>> Don't you need to specify exact version of library you depend on?
>
> It is up to distributions to care about the exact version of libraries
> that they provide. When they build and test harmony with these libraries
> the exact version will be recorded in the package.
Hang on - what do you mean "when they build and test harmony?" I'm sure
that some distros may do that - get the TCK license from Sun and test -
I'm not convinced it will be many. It will be up to us, at least at
first, to start doing certified builds for a matrix of precise versions
and distros. "harmony for linux" isn't going to cut the mustard.
geir
Re: [classlib][awt] X11 libs
Posted by Alexey Petrenko <al...@gmail.com>.
2006/12/1, Gregory Shimansky <gs...@gmail.com>:
> Alexey Petrenko wrote:
> > 2006/12/1, Gregory Shimansky <gs...@gmail.com>:
> >> 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.
> > Don't you need to specify exact version of library you depend on?
> It is up to distributions to care about the exact version of libraries
> that they provide. When they build and test harmony with these libraries
> the exact version will be recorded in the package.
I wanted to say that since package dependency specifies exact library
version then we can load exact version with dlopen without much
heuristics.
SY, Alexey
Re: [classlib][awt] X11 libs
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexey Petrenko wrote:
> 2006/12/1, Gregory Shimansky <gs...@gmail.com>:
>> 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.
> Don't you need to specify exact version of library you depend on?
It is up to distributions to care about the exact version of libraries
that they provide. When they build and test harmony with these libraries
the exact version will be recorded in the package.
>> 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 <gs...@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 <gs...@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
Re: [classlib][awt] X11 libs
Posted by Alexey Petrenko <al...@gmail.com>.
2006/12/1, Gregory Shimansky <gs...@gmail.com>:
> 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.
Don't you need to specify exact version of library you depend on?
SY, Alexey
> 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 <gs...@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 <gs...@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
>
Re: [classlib][awt] X11 libs
Posted by Tim Ellison <t....@gmail.com>.
+1 to the points that Gregory makes below
Regards,
Tim
Gregory Shimansky 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 <gs...@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 <gs...@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
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][awt] X11 libs
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <gs...@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 <gs...@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 <gs...@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
Re: [classlib][awt] X11 libs
Posted by Oleg Khaschansky <ol...@gmail.com>.
I am speaking about possibility of building awt on headless machine.
I mean that we cannot have three things at one time:
1. Headless support.
2. "distributions like Gentoo which build everything from source"
3. Other strategy then dlopen.
> 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.
On 12/1/06, Tim Ellison <t....@gmail.com> wrote:
> 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?
>
> Do you mean at runtime or build time? i.e. do you envisage a "headless
> build" which only allows you to build a headless implementation, or
> simply require that the code is capable of running headless by not
> requiring the x11 server at runtime. or both.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [classlib][awt] X11 libs
Posted by Tim Ellison <t....@gmail.com>.
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?
Do you mean at runtime or build time? i.e. do you envisage a "headless
build" which only allows you to build a headless implementation, or
simply require that the code is capable of running headless by not
requiring the x11 server at runtime. or both.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib][awt] X11 libs
Posted by Oleg Khaschansky <ol...@gmail.com>.
> 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?
On 12/1/06, Gregory Shimansky <gs...@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 <gs...@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 <gs...@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
>
Re: [classlib][awt] X11 libs
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <gs...@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 <gs...@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
Re: [classlib][awt] X11 libs
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky 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.
I don't like the "fetch me a rock" approach either, for all sorts of
reasons. First is compatibility - does this mean we need to test with
all possible variants of what the classlib could possibly load?
(and this is why I lean to static linking - no mysteries or surprises)
>
>> 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.
Hopefully.
geir
Re: [classlib][awt] X11 libs
Posted by Oleg Khaschansky <ol...@gmail.com>.
> 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.
> 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 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.
On 11/30/06, Gregory Shimansky <gs...@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 <gs...@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
>
>
Re: [classlib][awt] X11 libs
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <gs...@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
Re: [classlib][awt] X11 libs
Posted by Oleg Khaschansky <ol...@gmail.com>.
> 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? :)
Isn't dlopen/dlsym approach a dynamic linking?
Again, some API could be missing in some systems (opengl extensions,
for example), what would you suggest to do in this case?
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5011992
On 11/29/06, Gregory Shimansky <gs...@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
>
>
Re: [classlib][awt] X11 libs
Posted by Gregory Shimansky <gs...@gmail.com>.
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
Re: [classlib][awt] X11 libs
Posted by Oleg Khaschansky <ol...@gmail.com>.
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.
On 11/29/06, Tim Ellison <t....@gmail.com> wrote:
> Just pulling out Mark's recommendation and changing the subject to get
> the right people's attention.
>
> Mark Hindess wrote:
> > On 29 November 2006 at 9:24, Tim Ellison <t....@gmail.com> wrote:
> >> Mark Hindess wrote:
> >>> Actually it's another .so problem. This time does actually give the
> >>> meaningful error:
> >>>
> >>> Caused by: java.lang.Throwable:
> >>> java.lang.UnsatisfiedLinkError: Cannot load libXtst.so library
> <snip>
> >>> I've installed the development package on this machine so the problem
> >>> should disappear, but this really should be fixed in the source.
> >> Meaning? it should try to load the versioned names too?
> >
> > It should try to load versioned names first. We know classlib works
> > with X11R6 but I don't know if anyone has tested it with X11R4/5/7?
> > We should try to load libXtst.so.6 (and libXtst.so.7 if that has been
> > tested?) and then libXtst.so. It is clear from bug reports that (at
> > least) Debian and Ubuntu don't consider the lack of unversioned .so
> > files in runtime packages to be an error. So it is down to us to make
> > it work for the common case - i.e. only versioned .so file present.
>
> Sounds reasonable to me -- unless there are any objections I'll make the
> change.
>
> Anyone tested with R4/5/7 ? Do we expect them to work?
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>