[gentoo-dev] virtauls for libstdc++-versions?

[gentoo-dev] virtauls for libstdc++-versions?

[Sven Köhler]

Hi,

i don't want to submit a bug-report for every this and that, but i've 
got to say, that i miss virtuals vor the different libcstdc++ versions.

For example there are the gcc3.2/3.3 ebuilds, and the libstdc++-ebuild 
that supply the same libstdc++ versions. The virtuals will only be used 
by precompiled-stuff, but i think it's still necessary.

The same case perhaps applies to gcc2.9 and lib-compat - don't they 
supply the same libstdc++ versions?

Thx
   Sven


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtauls for libstdc++-versions?

[Mike Frysinger]

On Friday 25 June 2004 07:22 pm, Sven Köhler wrote:
> For example there are the gcc3.2/3.3 ebuilds, and the libstdc++-ebuild
> that supply the same libstdc++ versions.

if they have the same name down to the version number, they are supposed to 
binary compatible and i see no reason we should try to work around that

> The same case perhaps applies to gcc2.9 and lib-compat - don't they
> supply the same libstdc++ versions?

uhh file a bug maybe ?
-mike

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: virtauls for libstdc++-versions?

[Sven Köhler]

>>For example there are the gcc3.2/3.3 ebuilds, and the libstdc++-ebuild
>>that supply the same libstdc++ versions.
> 
> if they have the same name down to the version number, they are supposed to 
> binary compatible and i see no reason we should try to work around that

Sorry, i think you misunderstood me.

How would you modify the ebuild blackdown-jdk for example? It must 
express a dependency on gcc3.2/3.3's libstdc++, but it can't. There's no 
virtual for that yet.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: virtauls for libstdc++-versions?

[Mike Frysinger]

On Friday 25 June 2004 08:35 pm, Sven Köhler wrote:
> How would you modify the ebuild blackdown-jdk for example? It must
> express a dependency on gcc3.2/3.3's libstdc++, but it can't. There's no
> virtual for that yet.

stick it into lib-compat and have it depend on lib-compat
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] virtauls for libstdc++-versions?

[Travis Tilley]

On Friday 25 June 2004 07:22 pm, Sven Köhler wrote:
> Hi,
>
> i don't want to submit a bug-report for every this and that, but i've
> got to say, that i miss virtuals vor the different libcstdc++ versions.
>
> For example there are the gcc3.2/3.3 ebuilds, and the libstdc++-ebuild
> that supply the same libstdc++ versions. The virtuals will only be used
> by precompiled-stuff, but i think it's still necessary.

oh dear god no... i am not in any way searching and hunting for every single 
binary ebuild in the tree to update it's dependencies (after determining if 
it's c++, non-static, and linked against an older libstdc++). the 
libstdc++-v3 ebuild will be added to the gcc 3.4 profile for any arch with 
binary packages that might need it.

what problem do you want to solve using a virtual? or why would you want a 
virtual?

-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: virtauls for libstdc++-versions?

[Travis Tilley]

On Friday 25 June 2004 11:06 pm, Sven Köhler wrote:
> sorry sir. blackdown-jdk is compiled against gcc3.2. Since my system is
> based upon gcc3.4 i would have to emerge libstdc++-v3 manually, but
> that's only a workaround for the fact, that this hasn't been properly
> solved by using dependecy on virtuals.

the amd64 and ppc64 profiles that make use of gcc 3.4 include libstdc++-v3 in 
"emerge system". no other arch is right now completely supported.

possibly i should make gcc 3.4 PDEPEND on libstdc++-v3 on all archs known to 
have binary packages available that link against the older libstdc++? that 
way libstdc++-v3 would always be installed after gcc 3.4 on these archs and 
the problem would be solved. 

-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: virtauls for libstdc++-versions?

[Sven Köhler]

>>How would you modify the ebuild blackdown-jdk for example? It must
>>express a dependency on gcc3.2/3.3's libstdc++, but it can't. There's no
>>virtual for that yet.
> 
> stick it into lib-compat and have it depend on lib-compat
> -mike

sorry sir. blackdown-jdk is compiled against gcc3.2. Since my system is 
based upon gcc3.4 i would have to emerge libstdc++-v3 manually, but 
that's only a workaround for the fact, that this hasn't been properly 
solved by using dependecy on virtuals.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: virtauls for libstdc++-versions?

[Mike Frysinger]

On Friday 25 June 2004 11:06 pm, Sven Köhler wrote:
> sorry sir. blackdown-jdk is compiled against gcc3.2. Since my system is
> based upon gcc3.4 i would have to emerge libstdc++-v3 manually, but
> that's only a workaround for the fact, that this hasn't been properly

you missed the point

file a bug (if one doesnt already exist) requesting the libstdc++ from 
gcc-3.2.x and gcc-3.3.x be added to lib-compat :P
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: virtauls for libstdc++-versions?

[Travis Tilley]

On Saturday 26 June 2004 03:15 pm, Sven Köhler wrote:
> why should everybody have libstdc++-v3 installed? just some ebuilds that
> install pre-compiled software will depend on specific libstdc++ versions.

if you make me a comprehensive list of every binary c++ app/plugin in the 
portage tree linked against the old libstdc++, i'll update their 
dependencies. however, i dont assume anyone maintaining an app will 
automatically realise that this dependency is needed if using gcc 3.4... and 
there are a -lot- of ebuilds that would need updating, most of which arent 
even supported on my arch (so i cant test and dont want to touch them 
myself). perhaps spanky's idea of just slamming another binary into 
lib-compat is a good one...

> there also another point: somebody having gcc-3.2 or gcc-3.3 installed
> doesn't need libstdc++-v3 too, and the gentoo-way of solving that is to
> use virtuals.

true. but using profiles is a useful solution until we can get to -every- 
binary in the tree. :)

i even have a new dev on x86 who's interested in working on gcc-porting bugs 
and getting x86 ready for gcc 3.4: morfic. so this might be much more of an 
issue in the not-so-distant future... and one i will shamelessly drop in his 
lap. mwuahahahaha, it's good to have minions =D


-- 

Travis Tilley <lv@gentoo.org>

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: virtauls for libstdc++-versions?

[Sven Köhler]

>>sorry sir. blackdown-jdk is compiled against gcc3.2. Since my system is
>>based upon gcc3.4 i would have to emerge libstdc++-v3 manually, but
>>that's only a workaround for the fact, that this hasn't been properly
>>solved by using dependecy on virtuals.
> 
> the amd64 and ppc64 profiles that make use of gcc 3.4 include libstdc++-v3 in 
> "emerge system". no other arch is right now completely supported.

why should everybody have libstdc++-v3 installed? just some ebuilds that 
install pre-compiled software will depend on specific libstdc++ versions.

there also another point: somebody having gcc-3.2 or gcc-3.3 installed 
doesn't need libstdc++-v3 too, and the gentoo-way of solving that is to 
use virtuals.


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: virtauls for libstdc++-versions?

[Sven Köhler]

> oh dear god no... i am not in any way searching and hunting for every single 
> binary ebuild in the tree to update it's dependencies (after determining if 
> it's c++, non-static, and linked against an older libstdc++). the 
> libstdc++-v3 ebuild will be added to the gcc 3.4 profile for any arch with 
> binary packages that might need it.

LOL, so i got the point: it's to much work, so let it be.

You really convinced me.


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: virtauls for libstdc++-versions?

[Sven Köhler]

>>why should everybody have libstdc++-v3 installed? just some ebuilds that
>>install pre-compiled software will depend on specific libstdc++ versions.
> 
> if you make me a comprehensive list of every binary c++ app/plugin in the 
> portage tree linked against the old libstdc++, i'll update their 
> dependencies. however, i dont assume anyone maintaining an app will 
> automatically realise that this dependency is needed if using gcc 3.4... and 
> there are a -lot- of ebuilds that would need updating, most of which arent 
> even supported on my arch (so i cant test and dont want to touch them 
> myself). perhaps spanky's idea of just slamming another binary into 
> lib-compat is a good one...

So which ebuild will depend on lib-compat than? there's no list of that 
ebuilds, that's true, but just because there has been mistakes in the 
past, you shouldn't block improvements.

You should perhaps intruduce those virtuals now, and remove the 
workarounds later, when most of the ebuilds are using these virtuals.

>>there also another point: somebody having gcc-3.2 or gcc-3.3 installed
>>doesn't need libstdc++-v3 too, and the gentoo-way of solving that is to
>>use virtuals.
> 
> true. but using profiles is a useful solution until we can get to -every- 
> binary in the tree. :)

Sure, i don't want anybody to change every ebuild until tomorrow, but i 
think i discovered a m drawback which need to be handled better.

In addition, every C++ application in a system depends on some version 
of the libstdc++. The portage could even take care of that by 
determining which version of libstdc++ is used by the compiled binaries 
and adding a depency to the portage-database.


--
gentoo-dev@gentoo.org mailing list