SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Since I am not only ordinary desktop user, but software developer, I'm very interested in full versions(where it is possible) of software on my development and testing boxes. Under "full versions" I mean virgin binaries as they were born by builder and/or additional data files which can provide me all possible information about binaries, which is normally excluded or intentionally not included into packaging/distribution. In two words: debugging information.
So question: can I and where can I get such of/from Slackware distribution?
you will have to rebuild the packages you need with debugging turned on and avoid stripping them, modifying the corresponding slackbuilds: you will usually find debug turned off explicitly.
build scripts are made for end users that don't need heavier binaries/libraries with debug information (and gotta say that usually also developers don't like a slow O.S. )
you will have to rebuild the packages you need with debugging turned on and avoid stripping them, modifying the corresponding slackbuilds: you will usually find debug turned off explicitly.
Yes, I know I can. But consumed time almost equal infinity to achieve that.
Quote:
build scripts are made for end users that don't need heavier binaries/libraries with debug information
Well, storage size is not problem any more. And it is possible to strip-out most debug info, but it is impossible to recreate it from nothing. If user do not care about space. They always can run famous "find $ROOT | xargs file | grep -e "executable" -e "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded" as post-install action(in the same stage as creating initrd)
Quote:
and gotta say that usually also developers don't like a slow O.S.
OS speed have nothing with developers' love. That is end-user illness, not developers' one. Vice versa, slower development OS - more time left for developer to think out his task. In any case, presence of debug-info practically does not influences performance - another few second to load program does not make any problems, but another two hours to figure-out what means that segfaulted offset in that 3rd-party module does.
Slackware does not provide a separate debugging symbols package. Writing the build scripts to support both would seem a nice win-win for everybody. Perhaps this thread will help:
If building only for yourself, you could comment out the stripping commands in the build scripts and add the appropriate cmake/automake debugging option to the build flags. Yeah, I know, a lot of work to rebuild everything. Been there, done that.
One assumes that if the end-user knows what to do with debugging binaries, then he will certainly know how to create them. Hats off to those distros which *do* provide debug packages separately -but what a job to maintain them! Slackware used to provide a debugging package for glibc, but no longer does.
Indeed. Sometimes I wish the stock Slackware build scripts, or those scripts provided by the main repositories, would design the scripts so users could rebuild the packages along with a separate debugging symbols package. The default would be not to create them, but with a change in a single environment variable users could create the additional package. Just a wish.
One assumes that if the end-user knows what to do with debugging binaries, then he will certainly know how to create them.
As I said already, despite I know how to use "debugging binaries", I don't know how to create the from NOTHING. Yes, I can rebuild binaries from source but that will be other binaries no the same as in distribution, so any debugging information is unusable.
Quote:
The default would be not to create them, but with a change in a single environment variable users could create the additional package. Just a wish.
Little trick, which lefts unstripped binaries after SlackBuild(substitute strip by non-harmful binary)
( STRIP=$(which strip) ; mv "$STRIP" "$STRIP-real"; ln -s $(which true) $STRIP )
Spent a few hours to find possibility to set global flags for gcc/g++ - failed.
I don't know how to create the from NOTHING. Yes, I can rebuild binaries from source but that will be other binaries no the same as in distribution, so any debugging information is unusable.
why nothing? if you build them from the sources editing the slackbuilds (for CFLAGS, debug options and removing/commenting the stripping section) they will be like the distributed ones but with usable debug informations.
Quote:
Little trick, which lefts unstripped binaries after SlackBuild(substitute strip by non-harmful binary)
( STRIP=$(which strip) ; mv "$STRIP" "$STRIP-real"; ln -s $(which true) $STRIP )
Spent a few hours to find possibility to set global flags for gcc/g++ - failed.
I'm afraid you can't avoid editing the slackbuilds.
"if you build them from the sources editing the slackbuilds (for CFLAGS, debug options and removing/commenting the stripping section) they will be like the distributed ones but with usable debug informations" Unfortunately, this is not really true on Slackware. You'd have to rebuild them with the same mix of already-re-compiled libraries which were in use *at the time* the official build was made -which could be anytime during the last few years. Building the same versions from the same SlackBuilds is in no way a guarantee that you will get the same result as the standard package. This is because things only get re-compiled when 'needed' -which usually means when a bug/segfault gets noticed and reported by someone. In other words, binary compatibility and consistency is a hit-and-miss proposition.
Little trick, which lefts unstripped binaries after SlackBuild(substitute strip by non-harmful binary)
( STRIP=$(which strip) ; mv "$STRIP" "$STRIP-real"; ln -s $(which true) $STRIP )
Spent a few hours to find possibility to set global flags for gcc/g++ - failed.
Comment out the stripping commands in the build script. Then add the following environment variables:
Doing those steps will create a larger single package, but as long as you are building for your own purposes or limited distribution, everybody will be happy because they then can use the debugging symbols.
Be forewarned, in some case the new package will be significantly larger.
"significantly larger" can be up to 300 times larger in some cases! Not very ofetn, I'll admit, but it does happen. Usually it i2 more like 50%-100% larger.
Unfortunately, this is not really true on Slackware.
Not sure where your going with this.
If you recompile library A with debugging symbols kept in, you now have library A with debugging symbols and will then see them when using gdb, et al.
You will however have to recompile everything in the dependency chain to see everything or some symbols will have a very nondescript number instead of a name.
Quote:
In other words, binary compatibility and consistency is a hit-and-miss proposition.
This is a bit more of an issue, as recompiling library A may actually stop the error that your trying to debug.
What I mean is this. Take the gtk2 libraries for instance. There is no way to tell which version of glib2, glibc, etc was installed when they were compiled. It is quite likely that it was linked against a previous version of its' requirement, than the ones which are installed right now -whether you are running current or any of the standard install mixes. Slackware rarely recompiles dependent libraries when a library which is depended *on* gets upgraded, patched or re-compiled. Just in the last few days there has been a thread here where some program was segfaulting until it was re-compiled against the just-upgraded glibc -IIRC.
My point is that when you re-compile a Slackware source, you may or may not get resulting binaries which are functionally equal to those contained in the official package for that version. Compile-time configuration options and the mixture of what is installed and not installed at compile time can also effect the functionality/content of the resulting binaries.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.