Re: ${devlibs:Depends} results in libstdc++6-4.1-dev
On Thu, 17 Apr 2008, Andreas Tille wrote:
I get even at these days 3.4.6 (which is strange anyway) but which gives
no explanation for the 4.1 dependency I faced.
Hi,
I just found out the reason for the problem and most probably it is really
the same reason as reported in bug
If I apply the following patch
--- /usr/bin/d-devlibdeps 2008-02-28 00:32:40.000000000 +0100
+++ d-devlibdeps 2008-04-18 18:55:15.000000000 +0200
@@ -102,7 +102,7 @@
-e 's/libatk-1.0-0-dev/libatk1.0-dev/' \
-e 's/libxml2-2-dev/libxml2-dev/' \
-e 's/libgthread-2.0-0-dev/libglib2.0-dev/' \
- -e 's/libstdc++6-dev/libstdc++6-4.1-dev/' \
+ -e 's/libstdc++6-dev/libstdc++6-4.2-dev/' \
"${OVERRIDE[@]/#/-e}" \
I can force the depencency of the resulting -dev package to libstdc++6-4.2-dev
instead of libstdc++6-4.1-dev, which meand the dependency from a certain
libstc++6 version is hard coded inside d-shlibs. I think this is not the
right solution and might be a major blocker to get rid of gcc-4.1 because
we will have several dependencies from it which are just not needed. So
I wonder whether we might be able to find a more generic method to detect
the right libstdc++6 version we are building against. Something like
comes to mind - but I admit that I'm very unsure whether this is a really
good solution.
find /usr/include/c++ -maxdepth 1 -mindepth 1 -type d -exec basename \{\} \; | \
sort | head -n 1
It would work for me if I would use a variable instead of the hardcoded
4.1 - but I would like to hear your opinion first whether there might
be some reason for the hardcoded version before I file a patch for
something that in principle works like it should and just some documentation
is missing.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: