Re: building a library using gtk+
So I try to build a library. libglpp.a: $(OBJ3) GLPPmain.o #g++ -shared $(OPT) $(DEBUG) $(OBJ3) GLPPmain.o -o glpp.so `pkg-config --libs gtk+-2.0` $(LIBS) -lftgl ar r libglpp.a $(OBJ3) GLPPmain.o The first line did not work, and I'm hoping someone can give me the right set of command line arguments. I want to resolve the links to all the libraries and build a library of my own. The ar line works, but all it does is combine the objects into a library which does nothing to resolve the dependencies. I'm not sure, but can static/archive libraries have dependencies? I think you need to build a shared/dynamic library. rick jones still only getting started with all this... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: building a library using gtk+
On 5/16/06, Dov Kruger [EMAIL PROTECTED] wrote: If I run pkg-config and capture the output, this is what it puts out: -Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 So I want to build a library that builds in all the links to these libraries, because the user code does none of this and therefore shouldn't need to see all this nonsense. My code needs to be built against the gtk+ code, not the applications built on top of it. I handle this by making my own .pc file for my library. It's fairly easy to get your configure script to generate one and install it correctly, but I could post an example if you like. One you have a mylibrary.pc installed, your users can compile and link with: g++ main.cpp `pkg-config mylibrary --cflags --libs` and they should never need to see any gtk/glib/whatever nonsense. I imagine this would be easier than making a static library with the deps linked in. Although that's possible, it's rather fragile and you often find yourself losing some functionality (eg. glib's module loader can stop working). Plus on some platforms there are cflags (like -pthreads, or -D_REENTRANT) you need to set with code that links against gtk, even indirectly. You need a mechanism to do this sanely. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: building a library using gtk+
I handle this by making my own .pc file for my library. It's fairly easy to get your configure script to generate one and install it correctly, but I could post an example if you like. One you have a mylibrary.pc installed, your users can compile and link with: g++ main.cpp `pkg-config mylibrary --cflags --libs` and they should never need to see any gtk/glib/whatever nonsense. No, but if they for whatever reason happen to be using a different compiler than the one used to produce mylibrary, the pkg-config command could give them options specific to a compiler they aren't using. I've run into this a couple times while porting netperf4. rick jones portable adj, code that compiles under more than one compiler ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: building a library using gtk+
On 5/17/06, Rick Jones [EMAIL PROTECTED] wrote: I handle this by making my own .pc file for my library. It's fairly easy to get your configure script to generate one and install it correctly, but I could post an example if you like. One you have a mylibrary.pc installed, your users can compile and link with: g++ main.cpp `pkg-config mylibrary --cflags --libs` and they should never need to see any gtk/glib/whatever nonsense. No, but if they for whatever reason happen to be using a different compiler than the one used to produce mylibrary, the pkg-config command could give them options specific to a compiler they aren't using. I hadn't thought if that :-( I imagine it's relatively uncommon (none of the pkg-config output for gtk looks compiler-specific on OS X or Breezy), but you're right, it could be a problem. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk+ / DirectFb / Pango performance
Hi All - I'm hoping I can get some guidance here. I'm cross compiling Gtk+ (latest CVS) to an ARM9 board. DirectFB performance is great - I can fill the screen with text using DirectFB font rendering and it appears instantaneous to a user. However, Gtk / pango font rendering is incredibly slow. If I show a Gtk Window with a handful of labels, the text dribbles onto the screen. The bulk of the time is spent in pango_renderer_draw_layout_line (the first call is very slow - subsequent calls are much faster) and pango_renderer_deactivate. Since Gtk calls these every time it draws a label, the performance overhead is crippling. Does anyone have any recommendations for speeding this up? - Clif ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: building a library using gtk+
John Cupitt wrote: On 5/17/06, Rick Jones [EMAIL PROTECTED] wrote: I handle this by making my own .pc file for my library. It's fairly easy to get your configure script to generate one and install it correctly, but I could post an example if you like. One you have a mylibrary.pc installed, your users can compile and link with: g++ main.cpp `pkg-config mylibrary --cflags --libs` and they should never need to see any gtk/glib/whatever nonsense. No, but if they for whatever reason happen to be using a different compiler than the one used to produce mylibrary, the pkg-config command could give them options specific to a compiler they aren't using. I hadn't thought if that :-( I imagine it's relatively uncommon (none of the pkg-config output for gtk looks compiler-specific on OS X or Breezy), but you're right, it could be a problem. -pthread is one I come across often enough. sometimes even when GCC is the only compiler involved - something about revisions I suspect. rick jones ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: building a library using gtk+
Since originally posting this question, I've used the linker to try to create a dll. ar just assembles a number of .o files, I don't believe it resolves any symbols which is useless to me. So, I did ld -dll -o libglpp $(OBJ3) GLPPmain.o -L/opt/lib -lftgl -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -L/usr/X11R6/lib -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/ -lstdc++ -lGL -lGLU -lgtkgl-2.0 And it works except for ld: warning: cannot find entry symbol _start; defaulting to 0804ab94 Viewer.o(.text+0x10ad): In function `__static_initialization_and_destruction_0': /usr/include/c++/3.2.3/iostream:63: undefined reference to `__dso_handle' Controller.o(.text+0x961): In function `__static_initialization_and_destruction_0': /usr/include/c++/3.2.3/iostream:63: undefined reference to `__dso_handle' Style.o(.text+0xb95): In function `__static_initialization_and_destruction_0': /home2/dkruger/dev/GLPP/core/Style.cc:4: undefined reference to `__dso_handle' Style.o(.text+0xbcb):/home2/dkruger/dev/GLPP/core/Style.cc:5: undefined reference to `__dso_handle' ECOMModelGrid.o(.text+0x1e1b): In function `__static_initialization_and_destruction_0': /usr/include/c++/3.2.3/iostream:63: undefined reference to `__dso_handle' GLPPmain.o(.text+0x7e5):/usr/include/c++/3.2.3/iostream:63: more undefined references to `__dso_handle' follow make: *** [libglpp.a] Error 1 Please don't get hung up on the command line, which I am using only for test purposes. I can't use `pkg-config ...` with ld because it emits arguments suitable for the compiler, but: g++ `pkg-config ...` will presumably call the linker the same way with the right arguments. I just have to learn how to generate a .so from g++ as opposed to ld, where it was very clearly documented. The point here is to build a pre-linked file so that I don't have to resolve all the references. This will dramatically speed the build of applications that are layered on a basic toolkit but use only one API (OpenGL) and do not use any gtk stuff, even though the core opens a gtk window and sets it up. There is no reason to suppose that this approach is any less portable than the other, since the library can be built by dependency just as the rest of the code is. If the libraries were to change, my interface library should change, but I would have the same problem if the gtk libraries on the system were to change -- every program that calls them would potentially have the same dependency problem as the library, right? Thanks ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: building a library using gtk+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/17/2006 11:06 AM, Dov Kruger wrote: Since originally posting this question, I've used the linker to try to create a dll. ar just assembles a number of .o files, I don't believe it resolves any symbols which is useless to me. So, I did ld -dll -o libglpp $(OBJ3) GLPPmain.o -L/opt/lib -lftgl -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -L/usr/X11R6/lib -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/ -lstdc++ -lGL -lGLU -lgtkgl-2.0 And it works except for ld: warning: cannot find entry symbol _start; defaulting to 0804ab94 Viewer.o(.text+0x10ad): In function `__static_initialization_and_destruction_0': /usr/include/c++/3.2.3/iostream:63: undefined reference to `__dso_handle' Controller.o(.text+0x961): In function `__static_initialization_and_destruction_0': /usr/include/c++/3.2.3/iostream:63: undefined reference to `__dso_handle' Style.o(.text+0xb95): In function `__static_initialization_and_destruction_0': /home2/dkruger/dev/GLPP/core/Style.cc:4: undefined reference to `__dso_handle' Style.o(.text+0xbcb):/home2/dkruger/dev/GLPP/core/Style.cc:5: undefined reference to `__dso_handle' ECOMModelGrid.o(.text+0x1e1b): In function `__static_initialization_and_destruction_0': /usr/include/c++/3.2.3/iostream:63: undefined reference to `__dso_handle' GLPPmain.o(.text+0x7e5):/usr/include/c++/3.2.3/iostream:63: more undefined references to `__dso_handle' follow make: *** [libglpp.a] Error 1 Please don't get hung up on the command line, which I am using only for test purposes. I can't use `pkg-config ...` with ld because it emits arguments suitable for the compiler, but: g++ `pkg-config ...` will presumably call the linker the same way with the right arguments. I just have to learn how to generate a .so from g++ as opposed to ld, where it was very clearly documented. Right, you don't want to use the linker directly. Something like this should work: g++ -shared -o libglpp.so $(OBJ3) GLPPmain.o $(GTK_LIBS) $(GTKGL_LIBS) \ $(OPENGL_LIBS) $(WHATEVER_OTHER_LIBS) Where you've presumably filled in all the *_LIBS vars with the appropriate pkg-config calls, or just lists of libraries that don't change. Note that you should *not* manually link in libstdc++ here. g++ will do that for you. Now, this won't check for unresolved symbols. On linux, shared libraries are allowed to have unresolved symbols (at compile/link time, anyway; not at runtime in general). According to the 'ld' manpage, what you want here is the --no-allow-shlib-undefined option. To have g++ pass it to the linker, you'd pass '-Wl,--no-allow-shlib-undefined' to g++. I've never actually tried this, so I can't guarantee it will work. If you need to do a manual check for unresolved symbols, an inspection of the output of 'ldd -r -v libglpp.so' will tell you. Really, I think you're best off compiling your .o files with -Wall and making sure you're not calling nonexistant functions by examining warnings. That's the best way to avoid unresolved symbols due to typos, etc. (FYI, the '-dll' option you're using above is specific to x86 PE executables, i.e., win32.) The point here is to build a pre-linked file so that I don't have to resolve all the references. This will dramatically speed the build of applications that are layered on a basic toolkit but use only one API (OpenGL) and do not use any gtk stuff, even though the core opens a gtk window and sets it up. Will it really speed things up that much? We're talking about a shared library here that consists of only 7 object files, linked to a relatively small number of shared libraries. Unless you're compiling on really old systems, the speed decrease should be minimal. The reason I'd say building a shared library here would be so application developers don't need to have copies of those 7 object files, and you can also hide the internals of how you do things and change them at will. On a side note, why are you using gtk at all here? It's pretty trivial to open a simple window with xlib, and (presumably) associate it with an opengl context. There is no reason to suppose that this approach is any less portable than the other, since the library can be built by dependency just as the rest of the code is. If the libraries were to change, my interface library should change, but I would have the same problem if the gtk libraries on the system were to change -- every program that calls them would potentially have the same dependency problem as the library, right? Well, this approach isn't portable in the sense that if you link the library on one machine, and copy it to another non-identical machine, you could have problems. Since you're using g++, systems with different versions of libstdc++, or different versions of the compiler, would probably cause imcompatibilities. -brian
GTK 1.3 Windows problems *after a while*
Hi,I don't know if this will ring a bell, but I certainly hope so.Looking through archives, I haven't been able to find an answer to this...Using GTK 1.3.0 under Windows, I use the application, and after a long time of using it, it will eventually (but not always) begin to behave badly, icons will begin to disapper, and the application will become unusable... Something tells me it has something to do with the mix of GTK and OpenGL, but I can't be sure of that, as I can't pinpoint the source of the problem...Here are the kind of messages I get :MC254f_wxp.exe (pid:3416): ** WARNING **: gdk_gl_swap_buffers: GetDC failed MC254f_wxp.exe (pid:3416): Gdk-WARNING **: gdkwindow-win32.c:1534: CopyCursor failed: Opération réussie.MC254f_wxp.exe (pid:3416): Gdk-WARNING **: gdkdrawable-win32.c:1152: LineTo failed: Opération réussie. MC254f_wxp.exe (pid:3416): Gdk-WARNING **: gdkdrawable-win32.c:702: CreateCompatibleDC failed: Opération réussie.MC254f_wxp.exe (pid:3416): Gdk-WARNING **: gdkgc-win32.c:843: ExtCreatePen failed: Opération réussie. MC254f_wxp.exe (pid:3416): Gdk-WARNING **: gdkdrawable-win32.c:510: Polygon failed: Opération réussie.Is this behaviour something one of you has already met ?Is there a cure? :-pThank you very much, Philippe Morange.Mecalog. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: #80127 Rubberbanding issues
On Tue, May 16, 2006 at 05:37:06PM +0100, Ross Burton wrote: On Tue, 2006-05-16 at 12:25 -0400, Matthias Clasen wrote: II. The rectangle color is currently hardcoded to black, since that looks best with the default theme. Picking a shade of one of the theme colors for the rectangle color will not always turn out nice, so I think it might be a good idea to add a style property for this to GtkTreeView and default to black for the default theme. I recently removed one instance of hardcoded black from the treeview dnd code. It would be sad to reintroduce another one now; black does not work in hicolor-inverse and similar themes... And GtkTreeView uses fg_gc for this now. How about working out a shading of the theme colours that works for the popular themes (default and some other stock ones), and allow the other themes to override it if it looks bad for them. I've modified the rubberbanding code to use fg[GTK_STATE_NORMAL] as rubberbanding color and tried some different themes. This color seems to look good with all themes I tried, so I would propose to go for using the fg[NORMAL] color. thanks, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
