[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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



Reply to: