Hello Konstantin, folks, On Jan 16, 2008 5:25 PM, Konstantin Lupach <[EMAIL PROTECTED]> wrote:
> Mark, can you please comment what are the licensing issues preventing us > from libstdc++ redistribution you are talking about? There shouldn't any legal issues as soon as libstdc++ is LGPL'ed, but you could/should be ready to met some technical problems and unpredictable behavior ;). One of the Linux problem that almost all Linux distribution has it's own changes in the stack libc/libstdc++ and other system libraries including changes in the kernel, so it's better to use libstdc++ that installed in Linux distribution. External versioning we've talked above for the most UNIX distribution (external/internal versioning comes from SUN Solaris/SunOS) resolved with requirement to install compat-package (from vendor of Linux distribution) that just place in library pathes (/lib;/usr/lib and so on) libraries of the required versions. Automatically it could be solved with distribution in packages (rpm, pkg and so on). > > I do know it is allowed to redistribute this library even with commercial > products. > E.g. this is what Intel(R) VTune(TM) Performance Analyzer for Linux does. > > I also know that there are some technical issues/tricks with this > dependency. Let discuss them in a separate thread. > > Kind regards, > Konstantin Lupach > Intel Corporation > Nizhny Novgorod, Russia > > > On 1/16/08, Mark Hindess <[EMAIL PROTECTED]> wrote: > > > > > > On 16 January 2008 at 9:24, "Alexey Petrenko" < > [EMAIL PROTECTED] > > > > > wrote: > > > 2008/1/15, Konstantin Lupach <[EMAIL PROTECTED]>: > > > > Hi All, > > > > > > > > I gave a try these packages on Linux IA32 host > > > > with RHEL3 update 6 and noticed that both > > > > apache-harmony-jre-r603534-linux-x86-32-libstdc++v6- snapshot.tar.gz > > > > and apache-harmony-jre-r603534-linux-x86-32-snapshot.tar.gzrequire > > > > libstdc++.so.6. Was the 2-nd package built in a wrong compiler > > > > environment? > > > > > > > > The 2-nd question is about libstdc++ dependency. Why not to > > > > incapsulate this VM libraries dependecy? It can be either linked > > > > statically or if you want to reduce libraries size it is possible > > > > to put it to the build directory and provide a single IA32 package > > > > instead of 2 stdc++ dependent as it is done now. > > > Yes, we have this, I would say, ugly dependency. Which comes from ICU > > > as far as I remember. > > > > Not really. The dependency on libstdc++ comes from any library that > > includes C++ code so most of the awt and imageio libraries, and a number > > of libraries in the VM. The libstdc++5 specific dependencies from the > > default x86 icu is trivially avoided using the ant option. > > > > > I really believe that we should resolve this issue somehow. Do be > > > honest I'm tired of this type of failures with downloaded packages > > > myself. > > > > It doesn't seem to be something that has come up often on the -dev > > list. How much of a problem is this? > > > > > Any ideas or patches to fix this issue? > > > I'll investigate the problem deeper.... > > > > I'm not sure we can "fix" this issue - by distributing libstdc++ > > ourselves - because of licensing issues. > > > > Regards, > > Mark. > > > > > > > -- > Kind regards, > Konstantin Lupach > -- --vvl
