Gentoo is a source based distribution. This means that everything needed for a piece of software to be installed, pass through a delicate -sometimes- proccess called compilation and linking. PFL is a great solution for user searching which (not installed) package owns a single file - perhaps a header missing for the compiler - or the other way around, s/he can know what files an unkown ebuild installs. So every file must be to the rigth place for the compiler and if not the user must know how to retrieve it. S/he doesn't unpack every distfile to grep for it; s/he just use pfl's database of files and then emerge. And this brings me to the point : Just like every file, header or similar, every symbol - function must be accessible for the linker too. If ld is having a hard time with a symbol and it's reference (like bug 614572), the user hasn't any database to search ; instead s/he runs grep and search for a symbol in a whole lot of libraries. Who knows which one of these should be rebuild - if it present of course and we don't face a missing dependency like bug 642340. A psl-capable portage could then make use on nm to list *all* the symbols inside *all* of the libraries that a just-built package in ${TMPDIR} is about to install. This information can be stored both in a local and later in an online database for almost every ebuild. TL;DR psl could be a tool to collect and upload all the symbols a package's libraries have, just like pfl collects and uploads all the filenames of everything a package installs.
For bug 614572, you only have the read `man ceil` to find out that the build system should link with -lm. For bug 642340, soname search would be helpful. (In reply to Petross404(Petros S) from comment #0) > about to install. This information can be stored both in a local and later > in an online database for almost every ebuild. The soname data is currently available for local packages in /var/db/pkg/*/*/PROVIDES files, so an indexing service could use that. The 's' in psl should stand for 'soname' rather than 'symbol' ('symbol' is lower level).
(In reply to Zac Medico from comment #1) > For bug 614572, you only have the read `man ceil` to find out that the build > system should link with -lm. Or run this, because not every function has a man page : nm -Dn -o --defined-only /lib/* /usr/lib64/* 2> /dev/null | grep '\bceil\b' /lib/libm-2.26.so:000000000002f6c0 i ceil /lib/libm.so.6:000000000002f6c0 i ceil /usr/lib64/libm-2.26.so:000000000002f6c0 i ceil But that is still a good tip. > The soname data is currently available for local packages in > /var/db/pkg/*/*/PROVIDES files, so an indexing service could use that. > > The 's' in psl should stand for 'soname' rather than 'symbol' ('symbol' is > lower level). I am afraid I am missing something here. Isn't the whole point here, to query for undefined symbols (i.e. ceil) and not sonames (i.e. libm.so.6)?
It's backwards to lookup symbols provided by binaries, because programmers use library documentation in order to find out what functions are available, what headers they need to include, and what libraries need to be added to the linker arguments. Linking libraries via LDFLAGS is never the right thing to do, since it's the job of the build system to include necessary libraries in the linker arguments.
Just to be clear : I don't like linking via LDFLAGS either. The bug I posted was an example about the linker's error. Besides this, a user is just a user, not a developer. S/he only want's to find with ease, which package defines the symbol that ld has trouble with. If the library that is defining it is known, then the package that owns the library is also known, so it is re-emerged. I used to get these kind of errors when I mixed and matched non-LTO'ed packages with LTO'ed and until know I didn't know what to re-emerge with saner CFLAGS. LTO is more mature now, but one can still find a puzzling error about an undefined reference not knowing what to reemerge. Well, if only s/he knew where to look for it, like pfl.
Any news on this?
(In reply to Petross404(Petros S) from comment #2) scanelf can already do this: $ scanelf -qRys +ceil /lib64/ ceil /lib64/libm-2.25.so $ scanelf -qRys -ceil /lib64/ ceil /lib64/libiw.so.30 or run it on / with the -m flag to walk the whole rootfs. wrt nm, that only shows debugging info and is not good for looking up what a linker cares about. pfl was written by someone who wanted to do it. nothing is stopping anyone from coming up with something like "psl". that doesn't necessarily mean it needs or should be part of the portage core (at least initially). not sure what you're expecting here ... someone to write the package for you ?
Eerrr...Do I look like someone who has access to http://www.portagesymbolist.de/site/start ?
(In reply to Petross404(Petros S) from comment #7) assuming you actually mean http://www.portagefilelist.de and not http://www.portagesymbolist.de ... pfl isn't an official Gentoo project owned/maintained by Gentoo. so are you expecting us to be owners of that random project/website ? if you are actually referring to portagesymbolist.de, that domain isn't registered, so yes, you do have access to it.
Hi, PFL founder here. (In reply to Petross404(Petros S) from comment #0) > PFL is a great solution for user searching which (not installed) package Thanks. > TL;DR psl could be a tool to collect and upload all the symbols a package's > libraries have, just like pfl collects and uploads all the filenames of > everything a package installs. Awesome idea. Especially as it is not limited to Gentoo but everyone looking for symbols, isn't it? How could this work? Where to get the information from? How to grab them? Which information is needed to minimal answer the question? regards Daniel
