Re: [gentoo-dev] emerging a library with debugging symbols
On Sun, 03 Jul 2005 16:04:38 + Nelson Benítez <[EMAIL PROTECTED]> wrote: > Hello, Im trying to emerge a library (gnome-vfs) with debugging symbols > so gdb can show me sources when debugging. To accomplish this I have > emerged with pertinent cflags (-ggdb -O0) and with FEATURE "noclean" so > the sources are still around after emerging. But for some strange reason > the so file in the work directory has debugging symbols (not stripped) > but the so file installed hasn't debugging symbols (stripped), as you > can see here: > > file > /var/tmp/portage/gnome-vfs-2.10.1-r1/work/gnome-vfs-2.10.1/libgnomevfs/.libs/libgnomevfs-2.so.0.1000.1 > /var/tmp/portage/gnome-vfs-2.10.1-r1/work/gnome-vfs-2.10.1/libgnomevfs/.libs/libgnomevfs-2.so.0.1000.1: > ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped > > file /usr/lib/libgnomevfs-2.so.0.1000.1 /usr/lib/libgnomevfs-2.so.0.1000.1: > ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped http://dev.gentoo.org/~chriswhite/bugzilla-howto.html read the section on debugging with GDB for more information. > > > -- > gentoo-dev@gentoo.org mailing list > > pgpmJu4lfWOvI.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: qt.eclass
On Sat, Jul 02, 2005 at 01:43:43PM +0200, foser wrote: > On Fri, 2005-07-01 at 18:33 +0300, Dan Armak wrote: > > > calling a function in a global scope is a bad idea. it leads to lots of > > > unneccessary (and timely) computations > > Necessary in the case of kde split ebuilds. Take a look at > > kde-functions.eclass::deprange(). > > So you create functions to do things portage really should do ? Wouldn't > pushing the portage team to finally implement a major feature like > depranges be a better idea ? > > The gnome team has been dealing with these things forever, but we have a > preference for a global solution instead of inventing our own wheel. *cough* chip in. Kind of tired of hearing of "portage devs ain't doing anything", we _are_ actually attempting improvements, but people seem to be missing a somewhat obvious fact about development of portage. Consider this; if it were easy to implement, one might suspect it would have been implemented already. Nature of the portage code is that the stuff people want (I'm talking about mainly dep syntax expansion, remote crap etc, not tweaks to emerge output) is no longer low hanging fruit, nor has it been for quite sometime. Core problems in the code (design mainally) limit easily pulling off these features that those who don't look in the code think should be a one hour extension. Work is underway to try and fix things so that all of the stuff people have been poking about over the years is low hanging (whether implemented already, or easy to extend and pull off). If you want this stuff, know python or are willing to independantly bootstrap your python capabilities on an actual project, chip in, or pretty much sit back. Bit harsh, but help is needed, not bitching, nor further broken kludges slipped into the tree/portage source instead of trying to fix the actual underlying, _harder_ and further reaching problems. Y'all know FOSS, stuff gets implemented by those with either an explicit interest in a feature, or interest in the general improvement of a project- further effort invested is limited by the amount of time developers can realistically contribute. So... chip in. ~harring pgpfZwDGAJ10B.pgp Description: PGP signature
Re: [gentoo-dev] splitting build deps out from depends
On Fri, Jul 01, 2005 at 08:16:46PM -0500, Kito wrote: > Accurate deps should be a goal for the tree, a long term one > obviously... Picking at the words (not you), but "long term" == it gets ignored till someone starts screaming/foaming at the mouth. If BDEPEND were added, it's extra data that next version of portage could use to do crazy stuff, and it wouldn't screw up existing portage in anyway. What crazy stuff? Aside from having _full_ deps so we can trust portage not to do something stupid if the profile is missing, BDEPEND provides classification of a set of atoms that must be native to a system. Since there is a seperation of what is effectively chost (bdepend) and ctarget (depend), you're giving portage a classification of depends for a package that it can use to do (what I'm calling) interdomain deps. In other words for an arm x-compile target's BDEPENDs can be mapped back to the native host of the box. It allows the possibility for portage to natively support x-compile. Without it, it's not possible natively in portage, nor is the solution totally clean (imo at least). So... getting back to the long term bit, input in the here and now as to why this will never be implemented is required. Just to point out a bit again, the metapkg proposal will allow grouping of arbitrary atoms, so a virtual/c-toolchain could be used to collapse binutils/glibc/etc down to a single atom (indirection rocks, no? :) ~harring pgpTy0CoPZAVT.pgp Description: PGP signature
Re: [gentoo-dev] emerging a library with debugging symbols
On 05/07/03(Sun) 16:04, Nelson Benítez wrote: > Hello, Im trying to emerge a library (gnome-vfs) with debugging symbols > so gdb can show me sources when debugging. To accomplish this I have > emerged with pertinent cflags (-ggdb -O0) and with FEATURE "noclean" so > the sources are still around after emerging. But for some strange reason > the so file in the work directory has debugging symbols (not stripped) > but the so file installed hasn't debugging symbols (stripped), as you > can see here: > > file > /var/tmp/portage/gnome-vfs-2.10.1-r1/work/gnome-vfs-2.10.1/libgnomevfs/.libs/libgnomevfs-2.so.0.1000.1 > /var/tmp/portage/gnome-vfs-2.10.1-r1/work/gnome-vfs-2.10.1/libgnomevfs/.libs/libgnomevfs-2.so.0.1000.1: > ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped > > file /usr/lib/libgnomevfs-2.so.0.1000.1 /usr/lib/libgnomevfs-2.so.0.1000.1: > ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped > > > I think it could be something related to libtool when finally installing > the library but I have no idea, I would appreciate ideas for what is > happen here or what I am doing wrong... You haven't said anything about having "nostrip" in your FEATURES, so I'm guessing that's what you're missing... Patrick Börjesson -- PGP-Key: 4C5AB0BF PGP-Keyserver: subkeys.pgp.net pgpePaRg6tS2R.pgp Description: PGP signature
Re: [gentoo-dev] emerging a library with debugging symbols
3.7.2005, 18:04:38, Nelson Benítez wrote: > the sources are still around after emerging. But for some strange reason > the so file in the work directory has debugging symbols (not stripped) > but the so file installed hasn't debugging symbols (stripped), as you > can see here: What about FEATURES="nostrip" ? :) -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp1U3v1QCSuL.pgp Description: PGP signature
[gentoo-dev] emerging a library with debugging symbols
Hello, Im trying to emerge a library (gnome-vfs) with debugging symbols so gdb can show me sources when debugging. To accomplish this I have emerged with pertinent cflags (-ggdb -O0) and with FEATURE "noclean" so the sources are still around after emerging. But for some strange reason the so file in the work directory has debugging symbols (not stripped) but the so file installed hasn't debugging symbols (stripped), as you can see here: file /var/tmp/portage/gnome-vfs-2.10.1-r1/work/gnome-vfs-2.10.1/libgnomevfs/.libs/libgnomevfs-2.so.0.1000.1 /var/tmp/portage/gnome-vfs-2.10.1-r1/work/gnome-vfs-2.10.1/libgnomevfs/.libs/libgnomevfs-2.so.0.1000.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped file /usr/lib/libgnomevfs-2.so.0.1000.1 /usr/lib/libgnomevfs-2.so.0.1000.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped I think it could be something related to libtool when finally installing the library but I have no idea, I would appreciate ideas for what is happen here or what I am doing wrong... Thanks -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] ppp-2.4.3 ready for stable state
I want to mark net-dialup/ppp-2.4.3-r6 as stable on x86 and amd64 (the arches tested by me). Does anyone have a reason why it shouldn't be marked as such? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Re: /etc/env.d/46kdepaths belongs to arts.. error?
Dan Armak posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 02 Jul 2005 19:52:42 +0300: > On Saturday 02 July 2005 18:47, Duncan wrote: >> Dan Armak posted <[EMAIL PROTECTED]>, excerpted >> below, on Sat, 02 Jul 2005 15:33:34 +0300: >> > At least arts is going away with kde 3.x :-) >> >> I read the rumors on that about a year ago, [but have] heard >> essentially /nothing/ on it since then. > > I'm hardly a reliable source on this, I can only repeat what I've seen > on the kde-devel and kde-core-devel mailing lists That's more than I'd seen recently, so good enough for me! =8^) >> Back then, there wasn't even a solid proposal as to what would replace >> ARTS' various functions. The best solution seemed to be the >> desktop.org common solution, only nobody knew [what form it would >> ultimately take or when]. gstreamer and other possible partial >> solutions came up as well. > > I say aRts is going away because it's nearly or entirely unmaintained > for a long time now and has been declared dead many times in many > forums. AFAIK it's not been decided yet what to replace it with beyond > what you already wrote here. Declared dead, yes, but it's still walking among us... > I know there's a new thingy called kdemm, but it's just a framework > IIRC; it will still need a sound daemon doing mixing and output behind > the scenes. The daemon is what hasn't been decided on yet, but maybe > kdemm will support a choice of several (I've no idea if that'll happen). Actually, that last idea, supporting several, seems to ring a bell. I'd seen a framework mentioned as well, but nobody knew what it would look like originally. However, putting the pieces (the others are little more than side mention hints, but they fit nicely into the above, so I expect the picture I'm getting is as decently accurate as anyone can see at this point) together... I now believe kdemm is going to be as you mention the unified KDE part of the framework. The idea is to have a common API for KDE objects, with driver plugins for the various sound driver elements and platforms. I don't believe anything, therefore, is slated to directly replace the lower level functionality of ARTS (and indeed, from what I remember reading, the opinion is that one of the biggest problems with ARTS was it tried to be too much to too many, vastly complicating the situation, making maintenance a nightmare, and making it not really ideally good at anything). Rather, the general API kdemm framework is intended to keep things at a fairly high level, with individual output bridge-plugins for ALSA, JACK, OSS, gstreamer, etc, intended to function as middleware drivers, interfacing between kdemm and the various lower level platform drivers, whatever they may be. Keep in mind that QT4 now has a GPL version to run on MS platforms as well, and that KDE4 is being designed with an MSWindows port in mind too. The above kdemm framework idea, with the general kdemm framework remaining relatively high level, and output bridge-plugins filling the gap between it and the various platform sound-hardware drivers makes even more sense with this in mind, as kdemm as a KDE framework can then function on MSWindows with few to no changes at all, only a recompile with a suitable system compiler, and with an appropriate bridge-plugin interfacing to the MSWindows sound system as just one of a list of similar plugins filling the same functionality on the more traditional for KDE Unix platforms. As I said, that little bit you mentioned was just enough to start putting the pieces together!It makes perfect sense and all the pieces fit, tho, now that you provided the missing pieces. =8^) >> If there are any informative URLs[...] The latest release plan I see is >> still for 3.4.0 and dated from late last year! > > I guess that page will be updated sometime before the 3.5 release cycle > actually starts with alpha1... > > There's a 3.5 feature plan at > http://developer.kde.org/development-versions/kde-3.5-features.html, and > a recent short m/l thread about the release plan starts at > http://lists.kde.org/?l=kde-core-devel&m=111934060916267&w=2, which > isn't conclusive but is nearly so. PERFECT! Just what I wanted! Thanks. So... from reading, it looks like they are targeting KDE 3.5 feature freeze either just before aKademy (late Aug.), with a release to follow likely b4 Xmas vacation, or intending to leave the schedule a bit soft for now, freezing maybe a bit later, late Q3 or into Q4, when development has naturally seemed to slow down due to focusing on 4.0, with the 3.5 release then in the spring, leaving a smaller gap between it and 4.0. 4.0 then would be a year to a year and a half out (someone said two, but it was pointed out a year and a half is about as far out as it can go before it starts screwing things up, a la Debian's release that seemed it would never come, people deserting it, etc), later than June 2006, with a mention of KDE's 10th birthday, October-
