Re: Reducing unncessary string copying
* Joakim Sindholt opensou...@zhasha.com schrieb:
Sorry, I should have clarified:
* using a single byte resulted in a 15% CPU time overhead doing this
simple benchmark.
* using a full int it came down to about 10%
But this can probably be ignored in real world applications.
hmm, perhaps we'd need to create some real world test scenarios to find out ;-o
char *_strdup(const char *str)
{
int len = strlen(str);
char *r = malloc(len+1);
memcpy(r, str, len+1);
return r;
}
Not inlined or macro, so it will always do an full call.
Perhaps you could try it again w/ inline.
The idea was to take a function (global performance doesn't matter), and
make a version that takes a prefixed string, and one taking a regular
string. Inlining is not going to affect the benchmark and using the real
strdup wouldn't be a fair benchmark.
Okay.
BTW: what's g_strdup() actually doing under the hood ? calling libc strdup()
or everything on its own ?
(yes, yes, I should look at the code by myself ... ;-o)
The reason I came to this conclusion was really just because of the ABI
nightmare it would create. You'd have to modify every single application
in existance OR duplicate every API call ever that has a string in it
somewhere, which is also insane.
Right. That's also what botheres me. So better drop that stupid idea ;-o
I'm now checking if we could make internal (heap allocated)
structures smaller. Allowing those structures also on stack or in
.data could be helpful. Just trying to hack up something for GArray ...
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reducing unncessary string copying
* André Gillibert metaentr...@gmail.com schrieb:
Ok. If you pass around this structure as a value.
This indirectly increases the size of a data structure such as:
struct MyClass
{
GCStr some_string;
GCStr another_string;
} ;
And there are a lot of them...
snip
Copying a pointer (e.g. 8 bytes on 64 bits platform) requires less
code than copying a pointer and a char (which may occupy 16 bytes for
alignment purposes).
True. Perhaps we can find an better platform/arch specific solutions
(and only use this approach on those where not better solution
is available). On 64bit, we perhaps could steal the most-upper bit.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reducing unncessary string copying
* Joakim Sindholt opensou...@zhasha.com schrieb:
Hi,
I entertained these 2 approaches a bit and the general slowdown (on my
machine, an i686) resulted in approximately 10-15% overhead in the
following test duplicating strings:
hui!
But, I guess, your system is not under memory presure. (as mine ;-o)
snip
char *_strdup(const char *str)
{
int len = strlen(str);
char *r = malloc(len+1);
memcpy(r, str, len+1);
return r;
}
Not inlined or macro, so it will always do an full call.
Perhaps you could try it again w/ inline.
cstr cstrdup(const cstr str)
{
int len = strlen(str);
cstr r = (cstr)malloc(len+1+sizeof(cstrinfo))+sizeof(cstrinfo);
memcpy(r, str, len+1);
CSTR_INFO(r).flags = 0;
return r;
}
Maybe optimizable for certain archs.
I have however arrived at the conclusion that you should just leave C
strings alone and if it bothers you that much, use a different language
in the future. Frankly, regardless of approach, it will create an
ABI/API nightmare in existing libraries and applications using g_*
functions with strings.
hmm. my intention was to reduce the heap size. optimizing the
strings was my first idea.
perhaps we should also care of things like int sizes on 64bit, etc.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reducing unncessary string copying
* Yasushi SHOJI ya...@atmark-techno.com schrieb:
snip
it sounds, at least to me, more like a convention than new APIs
or a new class.
Yes, that would also be an idea. but in this case (when dynamic
data structures are filled out with those strings), we'll need
to track whether the string was copied anyways. But, of course,
that bit could be somewhere inside that data structure instead
of in each pointer/reference.
Oh, BTW, even when using my GCSTR approach, these dynamic structures
dont need to use it internally - they could easily convert it.
struct {
const char* title;
const char* description;
const char* blubbtext;
int flags;
...
} MyFoo;
#define MYFOO_STATIC_TITLE 1
#define MYFOO_STATIC_DESCRIPTION2
#define MYFOO_STATIC_BLUBB 4
MyFoo* foo_create(GCSTR title, GCSTR description, GCSTR blubb, int a)
{
MyFoo* foo = (MyFoo*)malloc(sizeof(MyFoo));
foo-flags = 0;
if (GCSTR_IS_STATIC(title))
{
foo-title = title.str;
foo-flags |= MYFOO_STATIC_TITLE;
}
else
{
foo-title = strdup(title.str);
}
...
}
void foo_delete(MyFoo* foo)
{
if (foo == NULL)
return;
if (!(foo-flags MYFOO_STATIC_TITLE))
free(foo-title);
if (!(foo-flags MYFOO_STATIC_DESCRIPTION))
free(foo-description);
...
}
how many bytes or how many CPU clocks are we waisting in
real world application?
Well, I didn't have a chance to do real measurements yet.
But my observation is that glib/gtk-based applications, even
small ones, are eating up much heap memory.
Anyways, I suspect the double size of ints and pointers seems
to be a larger problem than strings (I've noticed a huge increase
when switching vom 32bit gentoo to 64bit ubuntu - my system is
contigously swapping, sometimes even hanging for several seconds).
did you have a copy-on-write string class, like std::string in C++, in
your mind? having a copy-on-write string class in glib might be a
good idea.
Well, could be the next step. But I dont have a good solution
w/o (compiler-driven) destructors for that yet.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reducing unncessary string copying
Hi folks, I've observed in many C applications, often compile-time defined data like strings are copied unnecessarily. For example, if you pass names to certain objects (eg. opening a file, creating a window, etc) that will never change of disappear during the process' lifetime (eg. compiled-in), those strings dont need to be copied. Now the big question becomes: how to decide this ? I'm currently experimenting with a new string reference datatype that has an extra bit which tells whether the string is static. Essentially a struct consisting of the char* pointer and an extra byte for the flag. That struct then will be used instead of the const char* pointers. A few inline functions handle the conversion from/to normal const char* and on-demand copying. Just some theoretical example: Some function FOO* create_foo(const char* name) now becomes FOO* create_foo(GCStr name) and the call now would be create_foo(G_CSTR_STATIC(hello world)); in case we dont have an static string, but something with limited lifetime, it could look like this: create_foo(G_CSTR_DYNAMIC(bar)); Inside create_foo() we'll then replace g_strdup() by some G_CSTR_COPY() and g_free() by G_CSTR_FREE(). These functions will know whether the string has to be copied/free'd. Let's just leave the question of API-compatibility aside, what do you think about this idea ? greets -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Reducing unncessary string copying
* André Gillibert metaentr...@gmail.com schrieb:
This adds some level of indirection to access the data bytes, and some
space overhead.
For example, the string hello is 6 bytes long (including the zero
terminator), with GLIBC's malloc, it may occupy 8 bytes (or maybe 16
bytes).
With your implementation, it would occupy twice as much memory.
No. With my approach, strings aren't a single bit longer.
References to them require one more byte. (well, maybe more due padding).
On certain platforms/architectures (eg. 64bit), we maybe even could put
that single bit directly into the pointer (using the MSB if we can be
sure the upper half is never used).
Moreover, the binary code using strings would be larger of a few bytes too.
No. Plain access is not is not a single bit larger, ist just an offset.
My string reference looks like this:
typedef struct
{
gchar* str;
unsigned char flags;
}
And so, once g_strdup() has been called, a new dynamic string is
created. Consequently, very few strings would be static.
g_strdup() wont be called (directly) very often.
Code that is operating on my GCStry wont use that function, unless
it really wants a physical copy (eg. as buffer, etc)m instead if
uses G_CSTRY_COPY() which only copies non-static strings.
Storing the string as an array of bytes. The first byte of the array
would be the static bit, and the rest would be the string data.
Yep, also a good idea. Makes the required stack space smaller than
my approach. Perhaps could also be extended to do reference counting.
But: I'm currently lacking sufficient coffeine level to type down
a typedef+macro that a) makes writing string literals easy and
b) make it compile-type typesafe.
Perhaps something like:
typedef {
unsigned char flags;
unsigned char str[1];
} GCStr;
#define G_CSTR_LITERAL(s) (\1 s)
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: What is the problem that should be solved by that ? because this is the 21st century in which (1) applications consist of more than a binary executable I dont see a problem in this point. Actualy I'd prefer using even more separate binaries (and processes) for lots of architectural reasons. (2) users like easy-to-install-and-remove programs This is what distros and their packages are for. All the distros have their different use cases and audiencences and therefore valid reasons for their different approaches. (eg. Gentoo is not so different from Debian, just because they can, but because of the completely different scope) (3) ISV's like ways to provide users with easy-to-install-and-remove-programs That's what the distros's packaging toolchains are for. If upstream does a good job (clean architecture and codebase), the actually packaging efforts are quite minimal. (4) ISV's need to know that the versions of the library they are linked against is the correct one Proper dependencies and maybe additional checks in the configure stage (assuming that's *really* necessary) handle this. (5) applications written using C++ have a whole additional set of problems, which i will not detail here Well, I'm really interested in hearing them in detail. (6) some ISVs do not want their software to be primarily distributed by dozens of per-distro packagers. Simply install your bundled apps into some clearly specificed prefix (eg. /opt/my-app-name) The splintering of linux into dozens of different distros, all with their own particular foibles, means that its much easier to approach things from a bundle perspective. Not really. Perhaps on a quick look, but not in long terms. With those bundles you take the burden of many things that are normally the job of the distros. In the longer run, it just moves the problem, not solving it, and you'll also have to maintain all the bundled 3rdparty-packages. (I've seen a lot of projects where exactly this caused big problems, which just happened to become visible with a few years delay, but then became really ugly) Please be careful when comparing with the MacOs world - they have a really carefully engineered homogenous environment (which also imposes several constraints on the whole system architecture to make this all work), designed top-down. Completely different situation from the GNU world. All of this we're talking about right now are build and depolyment issues. Trying to solve them in an helper library like glib or gtk is fighting in the wrong place. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Hub Figui?re hfigui...@teaser.fr schrieb: -performs some changes to ldd to support linkage relative to the executable. I'm sure we can work around it with a shell-script wrapper; wrapper that might also be needed to support other OS, but I do believe it would be beneficial to investigate that possibility. ACK, that would be the quickest and easiest solution. And I have a very strange feeling with changing ldd's lookup semantics, beginning with serious security considerations. But: if the application bundle should be entirely self-contained, why using dynamic linking (of non-system-libaries) at all ? Actually, I'm entirely not convinces of the concept of self- contained applications at all. Sooner or later they will have to integrate/communicate with some other application (eg. beginning with tiny things like adding some menu entry or icon), and this will require some top-down coordination. And that's exactly the point where distributions come in. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: * as you note LD_LIBRARY_PATH takes care of this just fine, via a startup shell script. This covers just about all the *nix family. OS X requires nothing, which leaves Window where I have no idea. Maybe it's just a matter of fixing the libc on Windows, to support relative lookup pathes, etc. But btw: do we really need dynamic linking at all here ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Bastien Nocera had...@hadess.net schrieb: Em Thu, 2011-12-22 às 08:49 +0100, Enrico Weigelt escreveu: * Hub Figui?re hfigui...@teaser.fr schrieb: Maybe we could actually support bundles like it is done on MacOS. ./configure --prefix=foo ? It doesn't magically make libraries and binaries relocatable. Install it into some specific, standardized prefix and let process-local namespaces (eg. chroot+bind-mounts, etc) do the rest. Or simply install each application into its own namespace, similarily to package namespaces known in the Java world. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announce: glib-jsonrpc
* Joakim Sindholt opensou...@zhasha.com schrieb: Made a github repo. It's very much a WIP and I can't remember offhand exactly what's connected and what's not. https://github.com/zhasha/json-rpc-glib # Making all in json-rpc-glib # make[2]: Entering directory `/home/nekrad/foo/json-rpc-glib/json-rpc-glib' # CC libjson_rpc_glib_1_0_la-json-rpc-bridge.lo # cc1: error: unrecognized command line option -flto you've explicitly added command line options, which are only supported by new gcc compilers. see configure.in:34 (you also shouldn't add optimization flags explicitly, better leave this to the distro packagers) BTW: I had to explicitly disable introspection (on Gentoo), maybe it should be disabled per default. For the .mo's I'd suggest adding some prefix to the keys, to get around possible conflicts with other modules in the same process image. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: But: if the application bundle should be entirely self-contained, why using dynamic linking (of non-system-libaries) at all ? the GTK stack in particular cannot be statically linked (certainly not without considerable effort). Why not, exactly ? Actually, I'm entirely not convinces of the concept of self- contained applications at all. Sooner or later they will have to integrate/communicate with some other application (eg. beginning with tiny things like adding some menu entry or icon), and this will require some top-down coordination. And that's exactly the point where distributions come in. no, this is where defined APIs like the ones from freedesktop come in. You're assuming, any interaction between applications allowed is what's specified in that APIs. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: the GTK stack in particular cannot be statically linked (certainly not without considerable effort). Why not, exactly ? because quite a lot of GTK is dynamically loaded even if the basic what exactly is loaded dynamically, and why is the necessary ? libraries themselves are statically linked. and because the entire stack has a build system that pretty much assumes the the use case is dynamic linkage. how exactly ? no, this is where defined APIs like the ones from freedesktop come in. You're assuming, any interaction between applications allowed is what's specified in that APIs. if you want much more extensive integration, you're talking about desktop environments and apps written specifically to tightly integrate with them. I'm not just talking about desktop integration. What, eg., with integration with certain system resources, daemons, system-wide configuration, etc, etc ? as an ISV, i'm not really that interested in such things. i don't control nor do i want to control what DE's my users have, and i don't want my app dependent on the sort of concepts that DEs are now moving towards apart from a very limited common subset (e.g. presence in standard lists of applications, icons). Sure. Therefore you need some easy way for passing certain information to the DE, take for example menu entries or desktop icons. a) explicitly supporting a wide range of DE's, eg. by simply installing the necessary files to the DE's standard locations. - build time issue, can be easily put into an separate build helper tool b) have an extra system tool, which translates an abstract (DE-independ) source to the DE-specific files c) convince the individual DE-developers to directly support such abstract descriptor files But this doesn't really require things like binary relocation. I'm still not conviced. So, please let's go to the root questions: What are the exact problems you're trying to solve with binary relocation ? What are the desired use cases ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announce: glib-jsonrpc
* Joakim Sindholt opensou...@zhasha.com schrieb: You're absolutely right. There's also a lot of code in there that's incomplete and/or not connected. I just did a full commit of all the stuff I had in progress or way toying with before sending it to github. It's by no means indicative of what I would normally commit Okay. Once it reaches a stable point, I'd suggest a conservative code management using topic branches (merge only if the topic is finished and history contains only necessary and self- consistent changes, etc). This way you make distro package maintainer's life much easier. BTW: I had to explicitly disable introspection (on Gentoo), maybe it should be disabled per default. I think I just copied someone elses introspection stuff. It's more than likely completely wrong. Be careful with copy+paste. ;-) (one of my former customers have this as fundamental business concept, and I witnessed how they're slowly destroying themselves ;-o) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Paul Davis p...@linuxaudiosystems.com schrieb: what exactly is loaded dynamically, and why is the necessary ? * image file format loaders * font format handling * theme engines * various other modules That's what I already apprehended ... ;-o What's the exact reason for loading them dynamically ? I'm not just talking about desktop integration. What, eg., with integration with certain system resources, daemons, system-wide configuration, etc, etc ? neither GTK nor any DE needs to do anything about integration with things that are not part of GTK nor a DE. Well, but individual applications might need to. Think of stuff like socket pathes to certain daemons, etc. Runtime dependencies are a bit more than just shared objects ;-o Sure. Therefore you need some easy way for passing certain information to the DE, take for example menu entries or desktop icons. freedesktop covers all this. Okay, let's take this example: http://standards.freedesktop.org/menu-spec/latest/ It expects the menu entries in a specific location (beyond the prefix set by environment). AFAIK, the prefix itself isn't explicitly specified (just some suggested default), so it's dependent on the actual system configuration. Now we've got a problem with fully-relocatable applications: How does the DE know where's all these applications's installation prefixes are ? So, please let's go to the root questions: What are the exact problems you're trying to solve with binary relocation ? i don't even know what you mean by this term at present. Okay, we're talking about ways to deploy an arbitrary binary package (built somewhere else, fully out of the scope of the users's distro) to an arbitratry location. But: WHY ? What is the problem that should be solved by that ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Matthias Clasen matthias.cla...@gmail.com schrieb: If an app is in a single file, it can be copied and removed easily. The same can be easily done with an directory. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib resource framework
* Alexander Larsson al...@redhat.com schrieb: Maybe we could actually support bundles like it is done on MacOS. The idea of compiling data into a binary file give me a blast from the past from the MacOS 9 days. See: http://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distibution/ Congratulations. You've copied one of the really worst concepts of the windoze world. Desktop distributions like Fedora or Ubuntu work remarkably well, and have a lot of applications packaged. However, they are not as reliable as you would like. #1 Fedora always has been bad (IIRC just SuSE is even worse). #2 Ubuntu is probably one of the most stable distros around there, we're successfully using it for missing critical systems with millions of users. Do you really think that a single application development team can ensure application *and* system stability without close coorporation with the distro maintainers ? Most Linux users have experienced some package update that broke their system, or made their app stop working. Yes, especially when taking untested upstream packages directly. (speaking of which: certain upstreams are even still stupid enough for using AC_TRY_RUN, etc, ...) Linux users quickly learn to disable upgrades before leaving for some important presentation or meeting. Sane distros don't enable this on default. Every package installs into a single large system where everything interacts in unpredictable ways. For example, upgrading a library to fix one app might affect other applications This is exactly one of the major points what professional distros and their quality engeneering mechanisms are for. Installing software from untrusted sources always brings high risks. Package installation modify the system at runtime, including running scripts on the users machine. This can give different results due to different package set, install order, hardware, etc. Most of those problems come from bad upstreams or distro maintainers. Installing applications not packaged for your distribution Anyone yet had the idea that this might have some vaid reasons ? Maybe the distro maintainers consider that particular package not stable enough ? Installing a newer version of an application that requires newer dependencies than what is in your current repositories Blame the bad distro maintainers. Keeping multiple versions of the same app installed Why, exactly ? Keeping older versions of applications running as you update your overall system Such problems come from bad upstream or package maintainer. I imagine a system where the OS is a well defined set of non-optional core libraries, services and apps. Plan9 ? The platform is a small set of highly ABI stable and reliable core packages. It would have things like libc, coreutils, libz, libX11, libGL, dbus, libpng, Gtk+, Qt, and bash. Yeah, dbus, libpng, gtk+ and qt considered highly ABI stable. I just had to double-check the calendar, if I missed a few month and we've got April 1st again. All applications are shipped as bundles, single files that contain everything (libraries, files, tools, etc) the application depends on. Essentially dropping the concept of shared libraries. Bundles are self-contained, so they don't interact with other bundles that are installed. Why not just using containers or at least chroot's for that ? Installing them is as easy as dropping them in a known directory. Bypassing all fundamental security considerations. Then the bundle file itself is mounted as a fuse filesystem in a well known prefix, say /opt/bundle. Congratulations on the performance drop. Why not just using chroot's for that and leaving the rest as it is ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RFC: Rules for distro-friendly packages
Hi folks, I've collected several rules that upstreams should follow to make distro maintainer's life much easier. Feel free to comment on this: http://www.metux.de/index.php/de/component/content/article/57.html cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
* Emmanuele Bassi eba...@gmail.com schrieb:
Really ? did you measure it ?
it's been measured multiple times, on multiple platforms - especially on
embedded ones.
URL ?
How often do typically gtk applications get startet - how many
per second ?
that's absolutely inconsequential.
No. We're talking about gtk here, not any arbitrary library somwhere.
*any* application linking to glib and/or gtk+ would have that penalty
- and the *fewer* applications (such as your case) the worse it gets.
It gets worse because there's really a lot in this fat libraries
which only a small portion (or even none) of the installed
applications really use.
for better or worse, glib and gtk+ provide a platform (and ${DEITY}
knows how much I don't like that word); applications use the platform as
a whole or simply don't use it.
Aha, a fat thing, just like the .NET-platform, which you can either
eat or die, right ? Thanks, that makes the borderline clear.
Well, why not melting everything together, including the gnome stuff,
into one super-library, maybe even including the whole libc ? ;-o
Oh, btw, *If* you're really concerned about the dynamic linking
overhead, wouldn't it be the right way to improve ldso in general,
eg. by a kernel-based caching linker ?
feel free to poke the kernel and linker people to do it, then.
guess what, already working on that.
Well, on my system, only a few apps need gtk, and most of them only
small portions. You souldn't do the mistake of building everything
on unrealistic assumptions like gtk is only used in typical GNOME
environments.
oh, please. splitting up gtk and/or glib will yield the worst results on
small systems,
Do you have numbers ?
Some years ago (about when gtk2 came out), I've heavily trimmed it
down, removing everything that wasnt needed by the apps. On a P2 system
w/ ATA disks and 256M RAM, the overall system performance was about
10% faster.
after all, GNOME worked perfectly fine with dozens of little libraries
before. the performance gains in terms of environment start up time,
application start up time and memory usage have been documented and
verified.
Are we talking about gtk+ apps or the gnome environment at a whole ?
That are totally different issues. Gnome has a lot of other design
problems, which aren't scope of this list.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
* Michael Torrie torr...@gmail.com schrieb: Can you prove that it doesn't? Until you can, there's no logical reason to change the way GTK+ is currently done based on your say-so. There're a lot of other reasons for smaller libraries, for example reducing memory footprint, easier systems maintenance (smaller libs normally mean less changes, since many of them will be done elsewhere), easier code review (less code to look at per iteration), etc, etc. To blindly experiment on a massive scale as you propose is very expensive. I don't propose any blind experiments, but at least no more additions unless there's a damn good reasons to have it inside the current lib instead of a new one. For example, recent releases added several new widgets. They could have easily been implemented in their own libs. In the long run I imagegine a smooth way: #1: grouping functionality into distinct modules (eg. each non-basic widget will get one) and add dummy .pc files for them, telling the clients to use that. #2: split off the big gtk+ library into a core library (only the really fundamental parts), separate per-module libraries and create a (virtual) libgtk+ which pulls everything together. #3: fix the interface specification for core and modules and then tell clients to migrate to using them directly (instead of the old big one). Most GTK+ development is, of course, volunteer-based. And what has been done works well for many, many, people and companies, embedded or no. Yes, I'm well aware of that. I had done some works on gtk+ (especially for clean crosscompiling, trimmed-down builds, etc) several years ago but gave up due contigious frustration - nobody even listened to my arguments. I'm willing to spend a lot of resources into it again, if it won't be dropped away like that again. Oh, btw: once we've got the whole thing crosscompile'able in clean sysroot environments, I'm offering automated mass-builds and -tests (I'm speaking of hundreds to thousands of variations), But the crosscompiling issue is a primary constraint for that (cannot work w/o that, by design). Any change to GTK that slows GNOME down is likely going to be unacceptable, since that's where GTK+ is used the most. Do you have any proof that just the number of libraries is the root cause of a noticable slowdown ? I'd suspect other factors way more important. That said, GTK+ is being used quite nicely in a number of small, embedded environments. hmm, isnt v3.x going to drop directfb support ? well ... So is Qt, and Qt is at least as monolithic as GTK+. Qt is even worse than gtk. In any case I don't see GTK+'s size as being a problem in embedded development (yes I have done some embedded GTK+ developing in past years). Depends on how much resources your target platforms have and how much time you'd like to spend for a target-specific trimdown. Yes, that's exactly why I've given up gtk+ development. I simply dont have the spare manpower to drive everything on my own, and if I had, I'd start afresh with different very concepts. Your comment does not logically follow. Reducing the dependency on various, small libraries makes it easier to drive everything on [your] own. No, I was talking about the decision between splitting gtk+ or designing toolkit w/ similar functionality completely afresh. I case of a redesign I'd probably move away from the classical widget library approach towards an more intelligent GUI server, where clients speak to it via 9P channels and just describe the GUIs structure. (the actual GUI will then run in separate processes). But that's a completely different paradigm ... How does forcing you to examine numerous, dependent libraries and APIs make your life any easier? In the end, these APIs would be very small and state their purpose by their name. So for example an library name gtk-filechooser is self-explaining. Yes, my application will have a lot more separate dependencies, but I'll only have to write them down once - my build system will know what to do then. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
* Michael Torrie torr...@gmail.com schrieb: Hi, Why would you want to use directfb when a tiny X server is the same footprint and much better supported? Which one are you talking about ? Kdrive ? How good is it supported, especially on non-x86 platforms ? Xwindow generelly has several design drawbacks due its history and doesn't scale particular well in constrainted local-only applications, compared to Dfb+fusion. directfb is redundant. I hope you're not using it. I *am* using it, and it's far from being redundant. It reimplements (poorly) everything that X11 already does, like windows and events. No, not everything that X11, and for its purpose far more efficient. Qt is even worse than gtk. That's news to Nokia. Not only do they use it in Linux environment on their phones, they have also ported it to Symbian and it will become their main platform. Well, their decision. Smartphone GUIs are actually not the ideal candidate for the machine code paradigm, especially if you want things like 3rd-party applets, etc. Better take Android there. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
* Stefan Kost enso...@hora-obscura.de schrieb: I wonder how many dependencies are in between the widgets. If not many one could make gtk plugin based. Like having a gtkcore with the baseclasses, paint engine and event system only. All widgets are provided by plugins. That is a plugin can provide several widgets. And thus you can have e.g. gtkcorewidgets.so, gtkcoredialogs.so, ... . Plugin infrastructures need more complex things, like load and lookup mechanisms (at least for the factories). You loose build-time linking (for the plugins) and everything that's tied to it (eg. linker cannot check for missing symbols). And you need some generic interface to all widgets for passing proper construction or change information, since there won't be per-widget functions anymore. That IMHO only makes sense if you make the big step to a purely declarative paradigm, where the application only describes the GUI in some language and only steps in on specific events to retrieve or change some attributes. Something like HTML/DOM or XUL. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
* Paul Davis p...@linuxaudiosystems.com schrieb:
There're a lot of other reasons for smaller libraries, for example
reducing memory footprint, easier systems maintenance (smaller libs
normally mean less changes, since many of them will be done elsewhere),
easier code review (less code to look at per iteration), etc, etc.
you don't appear to understand how virtual memory interacts with
dynamic library linking, which means, fundamentally, that your
point about smaller memory footprint is just wrong. it would appear
that you think that because an application has a library mapped into
its address space that its memory footprint just grew by the size
of the library.
It grows as soon as certain pages are accessed. And - as already said -
unless the distinct functional (sub)modules are aligned into their
own pages instead of randomly cat'ed to one big contigious text section
on linker's will, there's great chance that there're many, many
never-accessed areas within pages that still have to be accessed
(and thus loaded).
its also been explaned to you how creating a massively variable
configuration for GTK actually increases the maintainance load.
I'm not talking about creating many configuration options, but
actually moving out functional modules to dedicated libraries.
I had done some works on gtk+ (especially
for clean crosscompiling, trimmed-down builds, etc) several years ago
but gave up due contigious frustration - nobody even listened to my
arguments.
it doesn't seem so suprising to me.
For me, too, as soon as I understood the total ignorance of constraints
and QM requirements in embedded systems.
That's just self-explaining:
excalibur gtk+-2.18.9 # find -type f -exec grep -E
AC_TRY_RUN|AC_CHECK_FILE {} ; | wc -l
8
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
* Emmanuele Bassi eba...@gmail.com schrieb: because loading tons of small libraries is actually going to cost much more in terms of resources (memory, I/O, linking and loading time) Really ? did you measure it ? How often do typically gtk applications get startet - how many per second ? Most of the time is spent in loading the pages (disk io). Yes, this can be done lazy (requireing many, many page fault exceptions, so driving up CPU load), but that will only help us if the text segment is clustered along usage pattern (IOW: by smaller modules within the fat library), otherwise we've got huge chance that the whole text will have to be loaded even if we actually just use small portions. With separate smaller libraries, that's already inherent. Oh, btw, *If* you're really concerned about the dynamic linking overhead, wouldn't it be the right way to improve ldso in general, eg. by a kernel-based caching linker ? than loading a single library shared by many (if not all) applications. Well, on my system, only a few apps need gtk, and most of them only small portions. You souldn't do the mistake of building everything on unrealistic assumptions like gtk is only used in typical GNOME environments. (otherwise it someday *will only* be used there and and loose the all the rest of the userbase). for the past five years there has been an impressive effort in reducing the amount of small libraries scattered across the platforms - Yes, that's exactly why I've given up gtk+ development. I simply dont have the spare manpower to drive everything on my own, and if I had, I'd start afresh with different very concepts. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
* Tshepang Lekhonkhobe tshep...@gmail.com schrieb: Maybe the patches may be useful to someone else, and you want to makethose available from one place, that is upstream. If upstream doesn't want it, lets make a downstream for (eg. in the OSS-QM project). I'm also concerned about continously increasing size and complexity. Back in 1.x-times I already tried to convince people here to split it into smaller libraries, but nobody listened - the chance at the 2.x step was not taken. That's why I don't even consider using glib and gtk+ for new apps. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
* Martyn Russell mar...@lanedo.com schrieb: On Tue, 2010-06-15 at 09:54 +0200, Tshepang Lekhonkhobe wrote: On Tue, Jun 15, 2010 at 01:16, Matthias Clasen That may be, but 'disable this random set of widgets I don't need' patches have very little chance of going upstream. Why do they have little chance of going upstream? The maintenance overhead is just not worth it and that's most likely the reason. When projects get to the size of GTK+ you really notice this overhead. The big question to me is, why has it grown to this size in the first place ? Why can't those things simply be in their own libs, ontop of gtk ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unloading sequence of GTK
* James Henstridge [EMAIL PROTECTED] schrieb: Hi, Its easier than people might think, and it reduces much of the code complexity. glib also makes some other prerequisites, so I dont see why an glib3-user couldn't be expected to go along with an gc ... One of the strengths of glib is that it can be used just about anywhere. If it relied on a GC, people would need to consider how that GC interacts with the rest of the application. For example, if you have Java and glib in the same process, do the two GCs interact properly? Why should they ? They both allocate their chunks from their own pool, so no one interfers with the other one's memory. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: rsync://sources.metux.de/metux-patches - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: modularize pango
* Behdad Esfahbod [EMAIL PROTECTED] schrieb: On Thu, 30 Mar 2006, Enrico Weigelt wrote: Hi folks, I'm going to modularize the fat pango package - split it into separate packages, one per module. If Pango is fat, what is Firefox or OpenOffice.org then? :) Even fatter ? snip How do you want to split it into separate packages? That's really a packaging issue best dealt with distros. Well, I actually dont have any distro. I'm building evrything from scratch up. The problem is: I need to configure my systems as small as possible. Okay, I could throw out evrything I think I don't need. But how to I know what is really needed ? If we've split it into separate modules, then the buildsystem will know - a simple pkg-config query would be enough for most cases. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: rsync://sources.metux.de/metux-patches - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: modularize pango
* Owen Taylor [EMAIL PROTECTED] schrieb: snip - Is the total size of Pango + modules large? No. For low memory systems (ie embedded): Yes. - Are the modules frequently updated without changes to the main part of Pango? No. This way you could legitimate the whole GNOME stuff in one package. Yes, X has been so, but this has been proven as hard to maintain, and so it's now modular :) - Are Pango and the modules separately maintained? Not really. Of course not, its one package. I can't see any possible reason that we'd want to make people's life miserable that way. What people exactly ? For me, as an Sysop w/ dozens of different and very individual configurations (mostly embedded) it would become much, much easier. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: rsync://sources.metux.de/metux-patches - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unloading sequence of GTK
* Tristan Van Berkom [EMAIL PROTECTED] schrieb: Hi, On an involved list such as this; I seriously doubt that nobody listened, alot of people probably put some quality time into deciding not to reply to such a proposal (dont be discouraged so easily :-D). well, in fact there was one reply (or even two ?). But nothing what I would cann an 'discussion'. If now someone's interested, we can talk about this again. GC is one of the major points I'd like to get in into glib3 ... cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unloading sequence of GTK
* Behdad Esfahbod [EMAIL PROTECTED] schrieb: snip Using a GC in glib means every application using glib should drag in the GC in too, which is not what glib developers going to accept I believe. Its easier than people might think, and it reduces much of the code complexity. glib also makes some other prerequisites, so I dont see why an glib3-user couldn't be expected to go along with an gc ... cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Unloading sequence of GTK
* Owen Taylor [EMAIL PROTECTED] schrieb: snip (*) Basically, it's impossible for GObject to know when a type is no longer in use, because we don't have garbage collection in C. Well, we could have. There're GC's for C out there, which seem to work quite good. I voted for that several years ago, but it seemed nobody listened ... ... as usual ... cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Success! Got gtk2 + xorg-modular built in SYSROOT-environment
* Behdad Esfahbod [EMAIL PROTECTED] schrieb:
Hi,
I'm not quite sure what a SYSROOT environment is.
It's a kind of jail, but for the toolchain instead of a
running system: evrything's taken from within the sysroot,
instead of the running system.
Probably the cleanest way of building for an foreign system,
not just for real crosscompiling.
snip
Anyway, you really should not patch configure scripts directly,
but patch configure.{in,ac} instead.
You're absolutely right. But the damage doesn't come from there,
and I dont like to engage on another front by trying to repair
autotools.
And why did you exactly need to write your own libtool?
Because I didn't see any chance for repairing the original one.
And because my implementation is just a frontend for an really
platform independent toolchain command set.
See: cvs://[EMAIL PROTECTED]/home/cvs/repositories/unitool
cu
--
-
Enrico Weigelt== metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: [EMAIL PROTECTED]
-
Realtime Forex/Stock Exchange trading powered by postgresSQL :))
http://www.fxignal.net/
-
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Success! Got gtk2 + xorg-modular built in SYSROOT-environment
Hi folks, after months of vading through the deep darkness of libtool and climbing along the abyss of autotools, I've now finally reached my destiny: I've finally got gtk2 (2.8) and all dependencies over pango, cairo, glib down to the xorg-modular packages built in an clean SYSROOT environment. This required me to patch a dozen of configure scripts manually (yeah, ugly and inconsitent!) and writing my own libtool ... Anyone interested in my works ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] - Realtime Forex/Stock Exchange trading powered by postgresSQL :)) http://www.fxignal.net/ - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
how to termlessly *enforce* crosscompile mode ?
Hi folks, I need to *enforce* the crosscompiling mode even when building for the same target architecture. It mostly works fine by passing the right toolchain commands via environment (in fact: pure-make / non-autoconf applications work almost perfectly with that), but configure is too stupid to recognize that I'm crosscompiling. Is there any way for enforcing it to work in crosscompile mode, aka never ever attempt to run anything of the freshly compiled code, absolutely termless ? I'm tired of fixing these overbloatet configure scripts by hand for every new version. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk2-2.8.4 build problem
hi folks, the configure script of gtk2-2.8.4 isn't able to detect X11, even if I pass the pathes directly (--with-x-includes etc), because its too stupid for passing the right pathes to CC when building the test program. Is there any consistent way for disabling all these reading of tea leaves and instead nailing the values directly into it ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
undefined reference to __rpc_thread_destroy
Hi folks, while trying to crosscompile gtk2 (2.6.4) I've got some errors on compiling the timescale executable: libgthread-2.0.so: undefined reference to `__rpc_thread_destroy' libgthread-2.0.so: undefined reference to `__res' libgthread-2.0.so: undefined reference to `_h_errno' libgthread-2.0.so: undefined reference to `_errno' Does anyone have an idea what's the problem ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: undefined reference to __rpc_thread_destroy
* muppet [EMAIL PROTECTED] schrieb: snip This sounds like your linker is trying to find an actual errno symbol because the C compiler didn't see the proper preprocessor definition of errno at .c - .o time. Check the includes and see if errno.h is being included. hmm. the strange thing is: the symbols are exported by libc, and it seems libc is linked. (the toolchain normally works). ldd shows up that libgthread isnt linked against libpthread, but IMHO ist should be. Does anyone have an idea what's the problem ? A description of the platform and toolchain would be invaluable. hmm, it's built with crosstool. gcc-3.4.2 on gnu/linux-2.6 I could post the whole build log if that helps. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Matthias Clasen [EMAIL PROTECTED] schrieb: snip Maybe just moving deprecated widgets to a separate library, like libgtk2.0-compat.la, would be a better solution? We'd get well maintained applications to avoid linking to this library, while at the same time keeping it around for those apps that just need it and whose authors are stuburn enough to not want to update. So let those apps depend on GTK+-2.x, like many depend on 1.2 now. Moving widgets to separate library will require some changes in related apps anyway. This gets proposed repeatedly, Unfortunately, it does not offer significant benefits that would justify the costs of doing this. Splitting GTK+ into multiple shared libraries increases the cost of symbol resolution. It does not reduce the memory consumption You're right, as long as we're talking about splitting such silly borders as proposed. We instead should move larger/more complex widgets and dialogs to their own library, or better to their own package. For example I dont see any reason for having something like a printer dialog layout around on my system if no one really uses it. snip significantly, since all the deprecated functions are unlikely to be paged in anyway. It does complicate the build considerably. Build would become much simplier if we had a bunch of smaller libs, divided on clear and useful borders. Well, it could even easier if we had an simple and deterministic buildsystem, but that's another story ... cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Banginwar, Rajesh [EMAIL PROTECTED] schrieb: I am really glad to see the intention of keeping the ABI same even with 3.0 release. I'm not. Binary compatibiliy prevents us from changes in the library structures, ie. which widgets belong into which lib. Normally a new major release introduces many heavy changes - that's why its called 'major'. No one every reall expects binary compatibility, or even full source compatibilty on new major releases. They're in fact different packages with different interfaces, just doing quite the same. If you wanna have binary compatibility, just stay in the 2.x line. Or with other words: if a new release is binary compatible with 2.x, it should also be called an 2.x. As we are going to include GTK 2.4 or 2.6 (based on distro feedback; e.g. Redhat ships with 2.4) in the first release of desktop module of LSB, having ABI compatibility even after platform consolidation is a welcome decision. You probably don't want this with an 3.0 seriously. Major releases are normally *large* changes and it will take time that applications become ported to the new interface. See gtk-1.x vs. gtk-2.x There are still a lot of gtk-1.x applications out there. gtk1 vs. gtk2 are completely different packages. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Rob Adams [EMAIL PROTECTED] schrieb: snip I don't really see much reason ever to break ABI for the forseeable future. There's essentially nothing stopping us from simply leaving deprecated functions in there indefinitely, other than a fairly minor Very *bad* idea. This breaks many applications sooner or later, and someone who's not involved in gtk will become really confused by that. Well, here we see the design of the first place: there is too much functionality in one library, which someday becomes obsolete, while the library at all won't. We have no clear interface borders. as Prof. Wirth already said years over years ago: make it as simple as possible. If we had some more libraries - devided by *functionality*, then if some functionality (ie. some widget) becomes obsolete, we simply dont maintain this lib anylonger. If these libs have their own packages, it gets even easier: there is no question about obsolete stuff - the packages just exist, and if someone wants to work on them, he just does. snip With this in mind, we have to start asking the question of what we think the version numbers for GTK actually mean. That's the point. AFAIK there's a wide consensous in the OSS world that jumps between major numbers break at least binary compatibility, even on source level. So on the other hand binary compatible releases should not do a major release jump. Major jumps should do something fundamentally new. We're not in the commercial world, where people rape version numbering for marketing. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Philippe De Swert [EMAIL PROTECTED] schrieb: snip This is an issue for embedded systems using gtk (like for example GPE). Maybe a --disable-deprecated flag could do the trick? Nice idea. BUT: it as to be absolutely clear what exactly this means. Just calling it obsolete is not enough. So better modelize several things considered obsolete as features, which can be switched by --enable-foo / --disable-foo. Of course the documentation and ./configure help should clearly state which features are obsolete. AND: before adding new features or functionality, think *really carefully* whether the new stuff *must* be in gtk and cannot reside in its own new library. snip (the last thing could also be done with a deprecated macro that warns during compilation as done in the Linux kernel) And if a certain feature is disabled, there should be macros for the disabled functions breaking the build with an appropriate error message (ie. function foo() reqiures obsolete feature foobar, which is currently disabled). So someone who's not an gtk developer can easily see what's happening. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Announcing: Project Ridley
* Florian Boor [EMAIL PROTECTED] schrieb: snip I'm working on the GPE project (http://gpe.handhelds.org, a software framework for mobile devices like PDAs) which is using GTK. Moving more features into GTK will make application development easier for us in a software environment of limited resources. I'm a little bit confused that you - as an embedded developer - a in favour of bloating up gtk ... snip The only problem i can imagine is that GTK might become heavily bloated and unusable on devices with limited resources. That's the major problem - not just for embedded devices. And therefore it simply shouln't be done. Separate things belong into separate libraries - evryone who needs a certain functionality is free to import the right libs for that. There's no need to put a whole operating system into one library. snip So please keep in mind that there are other projects than Gnome around using GTK which might run into trouble with the total size and memory usage of GTK and the fact that some things might be to heavy to belong to GTK. You're absolutely right. If gtk wants to become something like Qt, and only interesting for GNOME, just go on. Today, it's still an universal widget toolkit, not limited to GNOME, and I don't see what's bad about it. Gtk is already too fat, and the tendencies are not really good. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[PATH] pkg-config / $PKG_CONFIG fix
Hi folks, here's a little fix against configure to use always $PKG_CONFIG for calling pkg-config. I've got two versions, one against 2.6.4, another against 2.8.0. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - diff -ruN gtk+-2.6.4.orig/configure gtk+-2.6.4/configure --- gtk+-2.6.4.orig/configure Tue Jun 14 21:50:04 2005 +++ gtk+-2.6.4/configureTue Jun 14 21:53:15 2005 @@ -28410,7 +28410,7 @@ if test $pango_omitted_x_deps = yes ; then # Old versions of Xft didn't necessarily include -lX11 in the output -x_libs=`pkg-config --libs xft` -lX11 $X_EXTRA_LIBS +x_libs=`$PKG_CONFIG --libs xft` -lX11 $X_EXTRA_LIBS fi ## Strip the .la files diff -ruN gtk+-2.6.4.orig/configure.in gtk+-2.6.4/configure.in --- gtk+-2.6.4.orig/configure.inTue Jun 14 21:50:01 2005 +++ gtk+-2.6.4/configure.in Tue Jun 14 21:57:02 2005 @@ -1075,7 +1075,7 @@ if test $pango_omitted_x_deps = yes ; then # Old versions of Xft didn't necessarily include -lX11 in the output -x_libs=`pkg-config --libs xft` -lX11 $X_EXTRA_LIBS +x_libs=`$PKG_CONFIG --libs xft` -lX11 $X_EXTRA_LIBS fi ## Strip the .la files diff -ruN gtk+-2.6.4.orig/m4macros/gtk-2.0.m4 gtk+-2.6.4/m4macros/gtk-2.0.m4 --- gtk+-2.6.4.orig/m4macros/gtk-2.0.m4 Tue Jun 14 21:50:04 2005 +++ gtk+-2.6.4/m4macros/gtk-2.0.m4 Tue Jun 14 21:58:27 2005 @@ -27,7 +27,7 @@ AC_PATH_PROG(PKG_CONFIG, pkg-config, no) if test x$PKG_CONFIG != xno ; then -if pkg-config --atleast-pkgconfig-version 0.7 ; then +if $PKG_CONFIG --atleast-pkgconfig-version 0.7 ; then : else echo *** pkg-config too old; version 0.7 or better required. diff -ruN gtk+-2.8.0.orig/configure gtk+-2.8.0/configure --- gtk+-2.8.0.orig/configure Wed Sep 21 23:17:07 2005 +++ gtk+-2.8.0/configureThu Sep 22 01:17:49 2005 @@ -27800,7 +27800,7 @@ if $PKG_CONFIG --exists x11 xext; then have_base_x_pc=true X_PACKAGES=x11 xext -x_libs=`pkg-config --libs x11 xext` +x_libs=`$PKG_CONFIG --libs x11 xext` # Strip out any .la files that pkg-config might give us (this happens # with -uninstalled.pc files) diff -ruN gtk+-2.8.0.orig/configure.in gtk+-2.8.0/configure.in --- gtk+-2.8.0.orig/configure.inWed Sep 21 23:14:27 2005 +++ gtk+-2.8.0/configure.in Thu Sep 22 01:18:28 2005 @@ -1039,7 +1039,7 @@ if $PKG_CONFIG --exists x11 xext; then have_base_x_pc=true X_PACKAGES=x11 xext -x_libs=`pkg-config --libs x11 xext` +x_libs=`$PKG_CONFIG --libs x11 xext` # Strip out any .la files that pkg-config might give us (this happens # with -uninstalled.pc files) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
yet another configure trouble
Hi folks, i've got yet another configure problem: It doesn't find some parts of X11 (XIproto.h), because it doesnt use the right include path. config.log shows up, that no pathes are passed to gcc for the test - this of course cannot work. How can I build gtk2 nevertheless ? Am I forced to write my own buildsystem to replace configure ? cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- - ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
