From: Geert U. <ge...@li...> - 2003-09-11 15:55:12
|
Hi, I'm working on a virtual frame buffer device for UML that displays in a GDK/GTK window. The GDK/GTK frame buffer device works fine as a standalone application, but when compiled into the kernel things get more challenging. GTK needs GDK, X11, ..., and finally I need libpthread. As soon as I link the final image with -lpthread (even if it's not used/referenced anywhere else), the resulting image no longer boots, but hangs very soon. This is easily reproducible by doing: | tux$ gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc -o linux arch/um/main.o vmlinux -L/usr/lib -lutil -lpthread | tux$ ./linux | Checking for the skas3 patch in the host...not found | Checking for /proc/mm...not found | capture_stack : Expected SIGSTOP, got status = 0xb7f | tux$ ./linux debug | Checking for the skas3 patch in the host...not found | Checking for /proc/mm...not found | capture_stack : Expected SIGSTOP, got status = 0xb7f | tux$ Does anyone have a solution for this? Perhaps I have to `wrap' some symbols from libpthread? I noticed libpthread implements e.g. longjmp(), sigaction(), sigwait(), ... Or don't link with libpthread and implement the required pthread functionality myself in term of kernel threads and synchronization primitives? I seem to need at least these: pthread_cond_init pthread_cond_destroy pthread_cond_broadcast pthread_cond_signal pthread_cond_timedwait pthread_cond_wait pthread_setspecific pthread_getspecific pthread_key_create pthread_mutex_init pthread_mutex_destroy pthread_mutex_lock pthread_mutex_trylock pthread_mutex_unlock pthread_equal Thanks for your suggestions! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Gerd K. <kr...@by...> - 2003-09-12 08:40:16
|
Geert Uytterhoeven <ge...@li...> writes: > I'm working on a virtual frame buffer device for UML that displays in a GDK/GTK > window. What is the point of using gdk? I'd go with Xlib for that, if all you need is just a X11 window to blit the vitual framebuffer to IMHO isn't worth the trouble involved when using gdk/gtk. You just don't need all the fancy stuff provided by the toolkit ... Gerd -- You have a new virus in /var/mail/kraxel |
From: Geert U. <ge...@li...> - 2003-09-12 09:09:24
|
On 12 Sep 2003, Gerd Knorr wrote: > Geert Uytterhoeven <ge...@li...> writes: > > I'm working on a virtual frame buffer device for UML that displays in a GDK/GTK > > window. > > What is the point of using gdk? I'd go with Xlib for that, if all you > need is just a X11 window to blit the vitual framebuffer to IMHO isn't > worth the trouble involved when using gdk/gtk. You just don't need > all the fancy stuff provided by the toolkit ... GdkRgb is nice for displaying pictures, without having to care about X server visuals, etc. I.e. I need to write less code. And I want a few buttons to control the fbdev behavior. BTW, it's libX11 that needs libpthread... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Gerd K. <kr...@by...> - 2003-09-12 11:05:08
|
> > What is the point of using gdk? I'd go with Xlib for that, if all you > > need is just a X11 window to blit the vitual framebuffer to IMHO isn't > > worth the trouble involved when using gdk/gtk. You just don't need > > all the fancy stuff provided by the toolkit ... > > GdkRgb is nice for displaying pictures, without having to care about X server > visuals, etc. I.e. I need to write less code. I would probably try to map the X11 ximage format directly into linux framebuffer format, so you can use XPutImage() (or XShmPutImage()) to display the virtual framebuffer memory without any conversions. > And I want a few buttons to control the fbdev behavior. Well, ok, at this point it becomes very ugly with plain Xlib. What stuff do you want control there? > BTW, it's libX11 that needs libpthread... Oops. I'd expected it is one of the many gtk libs ... Gerd -- You have a new virus in /var/mail/kraxel |
From: Geert U. <ge...@li...> - 2003-09-12 11:19:20
|
On Fri, 12 Sep 2003, Gerd Knorr wrote: > > > What is the point of using gdk? I'd go with Xlib for that, if all you > > > need is just a X11 window to blit the vitual framebuffer to IMHO isn't > > > worth the trouble involved when using gdk/gtk. You just don't need > > > all the fancy stuff provided by the toolkit ... > > > > GdkRgb is nice for displaying pictures, without having to care about X server > > visuals, etc. I.e. I need to write less code. > > I would probably try to map the X11 ximage format directly into linux > framebuffer format, so you can use XPutImage() (or XShmPutImage()) to > display the virtual framebuffer memory without any conversions. > > > And I want a few buttons to control the fbdev behavior. > > Well, ok, at this point it becomes very ugly with plain Xlib. What > stuff do you want control there? - The rate at which the display is updated - The visual type (it's in fb_fix_screeninfo, so the user cannot specify it) - The frame buffer layout (it's in fb_fix_screeninfo), to e.g. debug code for bitplanes So at first I want to start with chunky 8 bpp 640x480, but later I want to add support for other pixel formats and visuals. GdkRgb allows to easily draw 8 bpp pseudocolor or grayscale, and 24 or 32 bpp RGB, and display it on whatever X server you have available. > > BTW, it's libX11 that needs libpthread... > > Oops. I'd expected it is one of the many gtk libs ... Me too, but it proved to be different... Right now I added dummies for the various needed pthread_* calls. The kernel starts fine, but as soon as I make calls to GTK or GDK it breaks. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Gerd K. <kr...@by...> - 2003-09-12 12:05:11
|
> - The rate at which the display is updated Ok. > - The visual type (it's in fb_fix_screeninfo, so the user cannot specify it) > - The frame buffer layout (it's in fb_fix_screeninfo), to e.g. debug code for > bitplanes Uh? Can a fb driver change them without fbcon becoming greatly confused? I think it is in fix for a reason ... > GdkRgb allows to easily draw 8 bpp pseudocolor or grayscale, and 24 or 32 bpp > RGB, and display it on whatever X server you have available. For debugging various modes that makes sense, althrough it probably isn't exactly fast ... Gerd -- You have a new virus in /var/mail/kraxel |
From: Geert U. <ge...@li...> - 2003-09-12 12:18:19
|
On Fri, 12 Sep 2003, Gerd Knorr wrote: > > - The visual type (it's in fb_fix_screeninfo, so the user cannot specify it) > > - The frame buffer layout (it's in fb_fix_screeninfo), to e.g. debug code for > > bitplanes > > Uh? Can a fb driver change them without fbcon becoming greatly confused? I think > it is in fix for a reason ... You cannot change them immediately, but if the changes would take effect on the next mode change it should work just fine. > > GdkRgb allows to easily draw 8 bpp pseudocolor or grayscale, and 24 or 32 bpp > > RGB, and display it on whatever X server you have available. > > For debugging various modes that makes sense, althrough it probably > isn't exactly fast ... You'd be surprised. At work I wrote an emulator for the graphics of a Set Top Box chip, which alpha blended various layers in different modes together. Redraw was done only if a particular region of the screen was changed. It was very usable, unless you drew individual pixels. For UML and fbdev user space I have to update the whole screen at regular time intervals, so it can be a bit slower. For UML and fbdev kernel space I can update the screen when it's redrawn, thanks to James' new drawing primitives in 2.6.0. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Henrik N. <hn...@ma...> - 2003-09-12 11:18:47
|
fre 2003-09-12 klockan 11.07 skrev Geert Uytterhoeven: > GdkRgb is nice for displaying pictures, without having to care about X server > visuals, etc. I.e. I need to write less code. And I want a few buttons to > control the fbdev behavior. > > BTW, it's libX11 that needs libpthread... What about running the X11 stuff in a helper and using mmap to map the framebuffer data in both the UML and the helper process? Regards Henrik -- Henrik Nordstrom <hn...@ma...> MARA Systems AB |
From: Jeff D. <jd...@ad...> - 2003-09-12 16:29:05
|
hn...@ma... said: > What about running the X11 stuff in a helper and using mmap to map the > framebuffer data in both the UML and the helper process? I'm not going to Geert how to do this, but I would like to see everything in one process. The reason is that I have fond hopes of turning UML into a library, libUML.so, which can be used by any app that needs anything provided by the kernel. So, if this is going to happen, libUML needs to be compatible with everything else out there, and this is one step in that direction. So, my preference would be to figure out what the incompatibility between UML and pthreads is, and fix UML. And I'll provide whatever help is needed to sort this out. Jeff |
From: Henrik N. <hn...@ma...> - 2003-09-12 22:25:12
|
On Fri, 12 Sep 2003, Jeff Dike wrote: > I'm not going to Geert how to do this, but I would like to see everything in > one process. The reason is that I have fond hopes of turning UML into a > library, libUML.so, which can be used by any app that needs anything provided > by the kernel. If you think it is feasible to run another heavy user of clone(), message queues and signals in the same process then it might be.. but my gut feeling is not.. > So, if this is going to happen, libUML needs to be compatible with everything > else out there, and this is one step in that direction. The use of helpers does not exclude the other.. but I see your point. Regards enrik |
From: Jeff D. <jd...@ad...> - 2003-09-13 18:54:30
|
hn...@ma... said: > If you think it is feasible to run another heavy user of clone(), > message queues and signals in the same process then it might be.. but > my gut feeling is not.. The only thing that worries me about clone is wait(). wait(-1, ...) is obviously dangerous if there are children floating around that you don't know about. Any properly careful user of wait will call it with the pids of children that it knows about. UML is not properly careful... Signals can be handled cleanly if handlers are chained. I don't know what message queues are. UML doesn't use anything by that name. However, I didn't think of the possibility of pthreads overriding system calls. That opens up whole new vistas of brokenness. Jeff |
From: Henrik N. <hn...@ma...> - 2003-09-13 21:01:11
|
On Sat, 13 Sep 2003, Jeff Dike wrote: > However, I didn't think of the possibility of pthreads overriding system calls. > That opens up whole new vistas of brokenness. It doesn't override system calls from what I know, but it does replace a whole lot of the glibc calls, some of which have the same name as some of the system calls.. (open, close, read, write, fcntl, recvmsg, sendmgs, sigaction, wait, waitpid, malloc, free and a whole lot more). Regards Henrik |
From: Geert U. <ge...@li...> - 2003-09-13 15:25:29
|
On Fri, 12 Sep 2003, Jeff Dike wrote: > hn...@ma... said: > > What about running the X11 stuff in a helper and using mmap to map the > > framebuffer data in both the UML and the helper process? > > I'm not going to Geert how to do this, but I would like to see everything in > one process. The reason is that I have fond hopes of turning UML into a > library, libUML.so, which can be used by any app that needs anything provided > by the kernel. > > So, if this is going to happen, libUML needs to be compatible with everything > else out there, and this is one step in that direction. > > So, my preference would be to figure out what the incompatibility between > UML and pthreads is, and fix UML. And I'll provide whatever help is needed > to sort this out. I compiled my own libpthreads, so I can easily remove code from it and see what happens. First step: libpthread redefines sigaction to install its own signal handler around the signal. If I remove this, UML runs until: | Initializing stdio console driver and quits without any further messages. If I try to run it under gdb, gdb crashes immediately with a segmentation fault. I'll be doing some more digging... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Jeff D. <jd...@ad...> - 2003-09-13 18:54:26
|
ge...@li... said: > First step: libpthread redefines sigaction to install its own signal > handler around the signal. Gawd, that's unpleasant. What does its signal handler do? > and quits without any further messages. If I try to run it under gdb, > gdb crashes immediately with a segmentation fault. Try stracing it. You can tell a lot about its progress by looking at its system calls. Jeff |
From: Geert U. <ge...@li...> - 2003-09-15 06:57:47
|
On Sat, 13 Sep 2003, Jeff Dike wrote: > ge...@li... said: > > First step: libpthread redefines sigaction to install its own signal > > handler around the signal. > > Gawd, that's unpleasant. What does its signal handler do? For reference, here's the code (from Debian glibc_2.3.1-16): | /* The wrapper around sigaction. Install our own signal handler | around the signal. */ | int __sigaction(int sig, const struct sigaction * act, | struct sigaction * oact) | { | struct sigaction newact; | struct sigaction *newactp; | | if (sig == __pthread_sig_restart || | sig == __pthread_sig_cancel || | (sig == __pthread_sig_debug && __pthread_sig_debug > 0)) | { | __set_errno (EINVAL); | return -1; | } | if (act) | { | newact = *act; | if (act->sa_handler != SIG_IGN && act->sa_handler != SIG_DFL | && sig > 0 && sig < NSIG) | { | if (act->sa_flags & SA_SIGINFO) | newact.sa_handler = (__sighandler_t) __pthread_sighandler_rt; | else | newact.sa_handler = (__sighandler_t) __pthread_sighandler; | } | newactp = &newact; | } | else | newactp = NULL; | if (__libc_sigaction(sig, newactp, oact) == -1) | return -1; | if (sig > 0 && sig < NSIG) | { | if (oact != NULL | /* We may have inherited SIG_IGN from the parent, so return the | kernel's idea of the signal handler the first time | through. */ | && (__sighandler_t) __sighandler[sig].old != SIG_ERR) | oact->sa_handler = (__sighandler_t) __sighandler[sig].old; | if (act) | /* For the assignment it does not matter whether it's a normal | or real-time signal. */ | __sighandler[sig].old = (arch_sighandler_t) act->sa_handler; | } | return 0; | } | #if 0 // FIXME UML sigaction | // FIXME: causes problems with UML | // Checking for the skas3 patch in the host...found | // Checking for /proc/mm...found | // capture_stack : Expected SIGSTOP, got status = 0xb7f | | strong_alias(__sigaction, sigaction) | #endif // FIXME UML As you can see, I have to uncomment the strong_alias(...) to make UML boot. > > and quits without any further messages. If I try to run it under gdb, > > gdb crashes immediately with a segmentation fault. > > Try stracing it. You can tell a lot about its progress by looking at its > system calls. Didn't help much neither... I removed all libpthread overridings of symbols that are used by UML (intersection of 'U' symbols of vmlinux and 'T' and 'W' symbols of libpthread), and now UML boots. I'll try to find out which one is the bad guy... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Henrik N. <hn...@ma...> - 2003-09-15 09:19:26
|
On Mon, 15 Sep 2003, Geert Uytterhoeven wrote: > On Sat, 13 Sep 2003, Jeff Dike wrote: > > ge...@li... said: > > > First step: libpthread redefines sigaction to install its own signal > > > handler around the signal. > > > > Gawd, that's unpleasant. What does its signal handler do? > > For reference, here's the code (from Debian glibc_2.3.1-16): The interesting part is what the signal handler does, not how it is installed. According to the code you quoted the signal handler is __pthread_signhandler or __pthread_sighandler_rt depending on the sigaction type. From my understanding of ptherads but without reading the code this signal handler is supposed to route the signal to the correct threads. Linux kernel signal management in cloned processes differs significantly from POSIX Threads signal specification and this signal routing tries to make Linux look more like the POSIX Threads specification. > I removed all libpthread overridings of symbols that are used by UML > (intersection of 'U' symbols of vmlinux and 'T' and 'W' symbols of libpthread), > and now UML boots. I'll try to find out which one is the bad guy... In this case I would say UML is one of the bad guys due to it's symbols which overrides libc or pthreads. Any application which needs to override libc primitives to work is a bad guy and pthreads is technically part of libc when using threaded applications. Hoever, if UML uses clone() or other libc calls (yes, clone() is a libc call, direcly matched by a kernel syscall) in a manner which should not confuse other users of the same calls then pthreads may be a bad guy as well, not dealing properly with the situation. Regards Henrik |
From: Geert U. <ge...@li...> - 2003-09-15 09:28:49
|
On Mon, 15 Sep 2003, Henrik Nordstrom wrote: > On Mon, 15 Sep 2003, Geert Uytterhoeven wrote: > > I removed all libpthread overridings of symbols that are used by UML > > (intersection of 'U' symbols of vmlinux and 'T' and 'W' symbols of libpthread), > > and now UML boots. I'll try to find out which one is the bad guy... > > In this case I would say UML is one of the bad guys due to it's symbols > which overrides libc or pthreads. Any application which needs to override > libc primitives to work is a bad guy and pthreads is technically part of > libc when using threaded applications. No, UML only _uses_ those symbols, libpthread redefines them in a way that breaks UML. > Hoever, if UML uses clone() or other libc calls (yes, clone() is a libc > call, direcly matched by a kernel syscall) in a manner which should not > confuse other users of the same calls then pthreads may be a bad guy as > well, not dealing properly with the situation. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Henrik N. <hn...@ma...> - 2003-09-15 10:51:22
|
m=E5n 2003-09-15 klockan 11.28 skrev Geert Uytterhoeven: > No, UML only _uses_ those symbols, libpthread redefines them in a way t= hat > breaks UML. uml redefines several libc symbols which does conflict with pthreads. The most notable is that uml overrides malloc/free but I think there is also a few other overrides due to kernel library calls having the same name as their libc equivalent calls. If you are to link with pthreads each of these must be verified to be threads safe to the same level as their libc/pthreads counterpart. On the positive side most kernel lib calls most likely are threads safe due to the multithreaded nature of the kernel, but any lib call making use of locking or other kernel constructs will almost certainly fail or cause problems if ever invoked from a pthread. Regards Henrik --=20 Henrik Nordstrom <hn...@ma...> MARA Systems AB |
From: BlaisorBlade <bla...@ya...> - 2003-09-16 18:43:22
|
Alle 12:51, luned=EC 15 settembre 2003, Henrik Nordstrom ha scritto: > m=E5n 2003-09-15 klockan 11.28 skrev Geert Uytterhoeven: > > No, UML only _uses_ those symbols, libpthread redefines them in a way > > that breaks UML. > > uml redefines several libc symbols which does conflict with pthreads. > The most notable is that uml overrides malloc/free but I think there is > also a few other overrides due to kernel library calls having the same > name as their libc equivalent calls. If you are to link with pthreads > each of these must be verified to be threads safe to the same level as > their libc/pthreads counterpart. On the positive side most kernel lib > calls most likely are threads safe due to the multithreaded nature of > the kernel, but any lib call making use of locking or other kernel > constructs will almost certainly fail or cause problems if ever invoked > from a pthread. There is(from long time) the idea to make possible turning UML into a libra= ry. This means that solving this issue in UML is worthwhile. I.e., let's suppos= e=20 that the malloc's conflict. Then, Uml will use uml_malloc, which will be is= =20 own version, and everyone will be happy. Using a -Dmalloc=3Duml_malloc woul= d=20 make unnecessary changing the source. This is a quick idea(and details abou= t=20 the exact names are to be tuned), but I hope it's useful. =2D-=20 cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729 EOSIGN |
From: Jan H. <bu...@uc...> - 2003-10-02 09:21:01
|
On Mon, Sep 15, 2003 at 11:19:11 +0200, Henrik Nordstrom wrote: > Hoever, if UML uses clone() or other libc calls (yes, clone() is a libc > call, direcly matched by a kernel syscall) in a manner which should not > confuse other users of the same calls then pthreads may be a bad guy as > well, not dealing properly with the situation. Just a side note: It's not overly direct. Libc does a LOT work before calling the syscall -- the libc call takes a function argument, while the syscall takes a stack pointer argument. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bu...@uc...> |
From: Jan H. <bu...@uc...> - 2003-10-02 09:09:48
|
On Fri, Sep 12, 2003 at 11:07:54 +0200, Geert Uytterhoeven wrote: > BTW, it's libX11 that needs libpthread... bulb@vagabond:~$ ldd /usr/X11R6/lib/libX11.so.6.2 libdl.so.2 => /lib/libdl.so.2 (0x400d5000) libc.so.6 => /lib/libc.so.6 (0x400d8000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) Not see libpthread anywhere around! However, I just checked gmodule and glib and neither seems to report libpthread either! However, I just ran the simplest gtk-2.0 program I could find a greped it's /proc/<pid>/maps for string pthr. NOT FOUND. Thus it really looks like gtk-2.0 application does NOT have to use pthreads! ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bu...@uc...> |
From: Geert U. <ge...@li...> - 2003-10-02 09:25:07
|
On Thu, 2 Oct 2003, Jan Hudec wrote: > On Fri, Sep 12, 2003 at 11:07:54 +0200, Geert Uytterhoeven wrote: > > BTW, it's libX11 that needs libpthread... > > bulb@vagabond:~$ ldd /usr/X11R6/lib/libX11.so.6.2 > libdl.so.2 => /lib/libdl.so.2 (0x400d5000) > libc.so.6 => /lib/libc.so.6 (0x400d8000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > Not see libpthread anywhere around! > > However, I just checked gmodule and glib and neither seems to report > libpthread either! ldd instead doesn't show it, but nm does: | tux$ nm -g /usr/X11R6/lib/libX11.a | grep pthre | U pthread_equal | U pthread_cond_broadcast | U pthread_cond_destroy | U pthread_cond_init | U pthread_cond_signal | U pthread_cond_wait | U pthread_equal | U pthread_mutex_destroy | U pthread_mutex_init | U pthread_mutex_lock | U pthread_mutex_unlock | U pthread_self | tux$ as does strings: | tux$ strings /usr/X11R6/lib/libX11.so | grep pthr | pthread_equal | pthread_self | pthread_mutex_lock | pthread_mutex_unlock | pthread_mutex_init | pthread_mutex_destroy | pthread_cond_init | pthread_cond_destroy | pthread_cond_wait | pthread_cond_signal | pthread_cond_broadcast | tux$ | tux$ dpkg -l | grep xlibs | ii xlibs 4.1.0-16woody1 X Window System client libraries | ii xlibs-dev 4.1.0-16woody1 X Window System client library development f BTW, during my investigation I found out that between glibc 2.3.1 and 2.3.2 the mechanism to override sigaction and some syscalls in libpthread was modified. In 2.3.1 libpthread just overrides the libc symbol (e.g. sigaction, open). In 2.3.2 libpthread defines e.g. __pthread_sigaction, and libc uses the weak symbol __pthread_sigaction to find out whether it has to use its internal implementation __libc_sigaction, or call libpthread's __pthread_sigaction. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Jan H. <bu...@uc...> - 2003-10-02 09:31:35
|
On Thu, Oct 02, 2003 at 11:24:11 +0200, Geert Uytterhoeven wrote: > On Thu, 2 Oct 2003, Jan Hudec wrote: > > On Fri, Sep 12, 2003 at 11:07:54 +0200, Geert Uytterhoeven wrote: > > > BTW, it's libX11 that needs libpthread... > > > > bulb@vagabond:~$ ldd /usr/X11R6/lib/libX11.so.6.2 > > libdl.so.2 => /lib/libdl.so.2 (0x400d5000) > > libc.so.6 => /lib/libc.so.6 (0x400d8000) > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > > Not see libpthread anywhere around! > > > > However, I just checked gmodule and glib and neither seems to report > > libpthread either! > > ldd instead doesn't show it, but nm does: GEEE, so fend of the LAST argument in that mail, which said: I *RAN* a simple Gtk2.0 application, greped it's /proc/<pid>/maps for string "pthr" and DIDN'T FIND IT. Which means, that during execution of that applications, libpthread WAS NOT IN MEMORY. If you thing it does not have to be there, well, I also greped strace of the application for the same string an it was not there. And all libraries are actualy _OPEN_ during execution. So neither was it ever READ in memory. Still don't consider that a sufficient proof it is NOT THERE? ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bu...@uc...> |
From: Geert U. <ge...@li...> - 2003-10-02 10:04:15
|
On Thu, 2 Oct 2003, Jan Hudec wrote: > On Thu, Oct 02, 2003 at 11:24:11 +0200, Geert Uytterhoeven wrote: > > On Thu, 2 Oct 2003, Jan Hudec wrote: > > > On Fri, Sep 12, 2003 at 11:07:54 +0200, Geert Uytterhoeven wrote: > > > > BTW, it's libX11 that needs libpthread... > > > > > > bulb@vagabond:~$ ldd /usr/X11R6/lib/libX11.so.6.2 > > > libdl.so.2 => /lib/libdl.so.2 (0x400d5000) > > > libc.so.6 => /lib/libc.so.6 (0x400d8000) > > > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > > > > > > Not see libpthread anywhere around! > > > > > > However, I just checked gmodule and glib and neither seems to report > > > libpthread either! > > > > ldd instead doesn't show it, but nm does: > > GEEE, so fend of the LAST argument in that mail, which said: > > I *RAN* a simple Gtk2.0 application, greped it's /proc/<pid>/maps for > string "pthr" and DIDN'T FIND IT. Which means, that during execution of > that applications, libpthread WAS NOT IN MEMORY. > > If you thing it does not have to be there, well, I also greped strace of > the application for the same string an it was not there. And all > libraries are actualy _OPEN_ during execution. So neither was it ever > READ in memory. > > Still don't consider that a sufficient proof it is NOT THERE? Hence _your_ simple application doesn't need libpthread. | gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl, --wrap,calloc -o linux arch/um/main.o vmlinux -L/usr/lib -lutil -L/usr/X11R6/li b -lgtk -lgdk -lX11 -lXi -lXext -lglib -lgmodule -ldl -lm -lgthread | /usr/lib/libglib.a(gutils.o)(.text+0x729): In function `g_get_any_init': | : warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | /usr/lib/libglib.a(gutils.o)(.text+0x71b): In function `g_get_any_init': | : warning: Using 'setpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | /usr/lib/libglib.a(gutils.o)(.text+0x731): In function `g_get_any_init': | : warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | /usr/lib/libglib.a(gutils.o)(.text+0x6c8): In function `g_get_any_init': | : warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | /usr/X11R6/lib/libX11.a(x11trans.o)(.text+0x6cb): In function `_X11TransSocketINETConnect': | : warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | /usr/X11R6/lib/libX11.a(x11trans.o)(.text+0x7cd): In function `_X11TransSocketINETConnect': | : warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking | /usr/X11R6/lib/libX11.a(XlibInt.o)(.text+0x74c): In function `_XEventsQueued': | : undefined reference to `pthread_equal' | /usr/X11R6/lib/libX11.a(XlibInt.o)(.text+0x766): In function `_XEventsQueued': | : undefined reference to `pthread_equal' | /usr/X11R6/lib/libX11.a(XlibInt.o)(.text+0x781): In function `_XEventsQueued': | : undefined reference to `pthread_equal' | /usr/X11R6/lib/libX11.a(XlibInt.o)(.text+0x79a): In function `_XEventsQueued': | : undefined reference to `pthread_equal' | /usr/X11R6/lib/libX11.a(XlibInt.o)(.text+0x7b7): In function `_XEventsQueued': | : undefined reference to `pthread_equal' | /usr/X11R6/lib/libX11.a(XlibInt.o)(.text+0xafc): more undefined references to `pthread_equal' follow | /usr/lib/libgthread.a(gthread.o)(.text+0x1d): In function `g_mutex_new_posix_impl': | : undefined reference to `pthread_mutex_init' | /usr/lib/libgthread.a(gthread.o)(.text+0x6f): In function `g_mutex_free_posix_impl': | : undefined reference to `pthread_mutex_destroy' | /usr/lib/libgthread.a(gthread.o)(.text+0xc9): In function `g_mutex_trylock_posix_impl': | : undefined reference to `pthread_mutex_trylock' | /usr/lib/libgthread.a(gthread.o)(.text+0x139): In function `g_cond_new_posix_impl': | : undefined reference to `pthread_cond_init' | /usr/lib/libgthread.a(gthread.o)(.text+0x247): In function `g_cond_timed_wait_posix_impl': | : undefined reference to `pthread_cond_timedwait' | /usr/lib/libgthread.a(gthread.o)(.text+0x2af): In function `g_cond_free_posix_impl': | : undefined reference to `pthread_cond_destroy' | /usr/lib/libgthread.a(gthread.o)(.text+0x320): In function `g_private_new_posix_impl': | : undefined reference to `pthread_key_create' | /usr/lib/libgthread.a(gthread.o)(.text+0x37e): In function `g_private_set_posix_impl': | : undefined reference to `pthread_setspecific' | /usr/lib/libgthread.a(gthread.o)(.text+0x397): In function `g_private_get_posix_impl': | : undefined reference to `pthread_getspecific' | /usr/lib/libgthread.a(gthread.o)(.data+0x24): undefined reference to `pthread_mutex_lock' | /usr/lib/libgthread.a(gthread.o)(.data+0x2c): undefined reference to `pthread_mutex_unlock' | /usr/lib/libgthread.a(gthread.o)(.data+0x38): undefined reference to `pthread_cond_signal' | /usr/lib/libgthread.a(gthread.o)(.data+0x3c): undefined reference to `pthread_cond_broadcast' | /usr/lib/libgthread.a(gthread.o)(.data+0x40): undefined reference to `pthread_cond_wait' | collect2: ld returned 1 exit status Convinced? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Jan H. <bu...@uc...> - 2003-10-02 13:52:43
|
On Thu, Oct 02, 2003 at 12:03:10 +0200, Geert Uytterhoeven wrote: > Hence _your_ simple application doesn't need libpthread. Hence NEITHER OF GTK, GDK, GLIB, GMODULE, GOBJECT, PANGO, ATK, X11 NEED libpthread! > | gcc -Wl,-T,arch/um/uml.lds.s -static -Wl,--wrap,malloc -Wl,--wrap,free -Wl, --wrap,calloc -o linux arch/um/main.o vmlinux -L/usr/lib -lutil -L/usr/X11R6/li b -lgtk -lgdk -lX11 -lXi -lXext -lglib -lgmodule -ldl -lm -lgthread However if you link with gthread, you need pthread. So: a) Please don't blame it on X11. b) Don't link against gthread unless you need them. b.1) If you only call Gtk stuff in one thread, you don't need them. b.2) If you call Gtk stuff from more than one thread, you can still provide gthread library with custom locking and get rid of pthread. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bu...@uc...> |