[Pkg-electronics-devel] preparation of gnucap-python 0.0.2-2 (Re: Processed: python3.6)

[Carsten Schoenert]

Hi,

Am 17.01.19 um 16:34 schrieb Felix Salfelder:
>> You need to read a bit between the lines I guess.
> 
> I looked closer and it actually found 3 warnings about unnecessary -ldl.
> This will be fixed in 0.0.3, i put in a workaround.

that's classical overlinking, something different than the massive
warnings about non found symbols. But also good if this is fixed.

> 2 more are about debian/tmp.out, "the hack".
> 
> - binaries to analyze should already be installed
>     but it's not, because it is the hack file.
> - package could avoid a useless dependency
>     no. these are the only purpose of the hack
> 
> nothing sensible i can do about these.

I don't know here enough about the circumstances around gnucap* and
especially the python bindings you have built so I can't say something
useful.

>> There are some lines that referring a symbol that is made of C++ code,
>> these symbols must come from your package and if not would mean some
>> other package is shipping library with unsolvable symbols with would be
>> serious issue of course.
> 
> I used "dh_shlibdeps -- -v" to see all of them.

This will not help here, it make the situation even "worse" as you will
get flooded by more lines about the basically same issues.

>> To solve this you need to tell dh_shlibdeps were this symbol can be
>> found, I bet within your private libs.
> 
> I don't understand. there is a private library, libgnucap-python.so with
> a hand full of symbols. dh_shlibdeps warnings does not mention these. To
> be sure, I then uninstalled libgnucap-python.so, and they still resolve,
> hinting that dh is doing the right thing.

dh_shlibdeps is just a helper that tries to look into the binaries and
than *tries* to find the library (in detail the Debian package) which
contains the symbol. But it's smart enough to distinguish between the
symbols from the package itself and "external" symbols.
If the symbol can't be resolved that a warnings is printed. Not more and
not lest is dh_shlibdeps doing.

But you can control the behavior it acts.

> the other symbols are all either libgnucap or python (unless i am
> missing an outlier).
> 
> I am still convinced that "it's probably a plugin" correctly describes
> the situation and that the manual is right in disregarding these
> warnings. What else could I do? the whole intent is to resolve these
> symbols when loading the plugin.
> 
>> The other messages about all these symbols from the Python libraries are
>> similar. dh_shlibdeps don't know were these symbols can be found because
>> it ha no information where to search for them.
> 
> Which i think is the correct behaviour. 

I wouldn't call this correct behavior, at least on my side some bells
are ringing as for me such an output isn't normal and show that
somethings isn't working as it should. For me this is using the tools
not correctly.

What about compiler warnings? These are also just warnings. Do you
ignore them also, obviously not. :)

> afaict, there is no package dependency implied by these symbols.

Of course not, simply because dh_shlibdeps can't extract which these
would be. And that's the danger about I've written. You need to prove
that the output is correct.

...
> good to know. However, -l will only help resolving local symbols, such
> as in private libraries, which do not seem to be the issue.

You are sure?

> dpkg-shlibdeps: warning: debian/python3-gnucap/usr/lib/python3/dist-packages/gnucap/_component.cpython-37m-x86_64-linux-gnu.so contains an unresolvable reference to symbol _ZN9COMPONENT9tr_reviewEv: it's probably a plugin

> root at x260:/build/gnucap-python-0.0.2# c++filt _ZN9COMPONENT9tr_reviewEv
> COMPONENT::tr_review()

> $ git grep "tr_review()"
> gnucap/_e_cardlist.i:   TIME_PAIR  tr_review();
> gnucap/_e_elemnt.i:  TIME_PAIR tr_review();
> gnucap/s_tr_swp.cc:  TIME_PAIR time_by = CARD_LIST::card_list.tr_review();
> misc/d_coil.cc:  TIME_PAIR tr_review()          {return TIME_PAIR(NEVER,NEVER);}

So this symbols comes from your code I guess. I've no idea where this
ends and in which binary. But that part is missing for dh_shlibdeps.

>> Maybe someone here on the list can give further pointing, otherwise
>> debian-python will be the right place for getting in contact.
> 
> I am totally interested, but i have to postpone it.

For now it's o.k. to live the current output, but it should really get
some attention in the future.

-- 
Regards
Carsten Schoenert