From: David O. <di...@wa...> - 2001-11-05 16:40:29
|
Hi, I am becoming completly mad. I'm trying to compile/install all the libs and apps that form e17 from the CVS. I'm using a Potato Debian which has been (succesfully) upgraded to a Woody. So the glibc I'm using is 2.2.4, I guess. Edb compile and install ok. No problem so far. Imlib2 compile and install ok. But from here any program that use the Imlib2 segfault within the dlopen function, trying to load the xpm.so image loader. Note that the imlib2_test program even segfault before main() is called! Can someone help me before I became crazy? Thanks, DindinX -- di...@wa... Quantum Mechanics is a lovely introduction to Hilbert Spaces! -- Overheard at last year's Archimedeans' Garden Party |
From: David O. <di...@wa...> - 2001-11-06 00:49:22
|
Hi, I am becoming completly mad. I'm trying to compile/install all the libs and apps that form e17 from the CVS. I'm using a Potato Debian which has been (succesfully) upgraded to a Woody. So the glibc I'm using is 2.2.4, I guess. Edb compile and install ok. No problem so far. Imlib2 compile and install ok. But from here any program that use the Imlib2 segfault within the dlopen function, trying to load the xpm.so image loader. Note that the imlib2_test program even segfault before main() is called! Can someone help me before I became crazy? Thanks, DindinX -- di...@wa... Applause, n: The echo of a platitude from the mouth of a fool. -- Ambrose Bierce |
From: Carsten H. (T. R. <ra...@ra...> - 2001-11-06 21:33:36
|
On Mon, 5 Nov 2001 05:52:41 +0100 David Odin <di...@wa...> babbled profusely: > > Hi, > > I am becoming completly mad. > > I'm trying to compile/install all the libs and apps that form e17 from > the CVS. > > I'm using a Potato Debian which has been (succesfully) upgraded to a > Woody. So the glibc I'm using is 2.2.4, I guess. > > Edb compile and install ok. No problem so far. > Imlib2 compile and install ok. But from here any program that use the > Imlib2 segfault within the dlopen function, trying to load the xpm.so > image loader. Note that the imlib2_test program even segfault before > main() is called! > > Can someone help me before I became crazy? downgrade your gcc/binutils. then it all works happily > Thanks, > > DindinX > > -- > di...@wa... > Applause, n: > The echo of a platitude from the mouth of a fool. > -- Ambrose Bierce > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9362 |
From: Tom G. <to...@li...> - 2001-11-06 21:43:03
|
* Carsten Haitzler (ra...@ra...) wrote: > On Mon, 5 Nov 2001 05:52:41 +0100 David Odin <di...@wa...> babbled > profusely: > > I am becoming completly mad. > > > > I'm trying to compile/install all the libs and apps that form e17 from > > the CVS. > > > > I'm using a Potato Debian which has been (succesfully) upgraded to a > > Woody. So the glibc I'm using is 2.2.4, I guess. > > > > Edb compile and install ok. No problem so far. > > Imlib2 compile and install ok. But from here any program that use the > > Imlib2 segfault within the dlopen function, trying to load the xpm.so > > image loader. Note that the imlib2_test program even segfault before > > main() is called! > > > > Can someone help me before I became crazy? > > downgrade your gcc/binutils. then it all works happily It's just binutils. But raster, we do have to fix this. We can't keep telling people to downgrade. It _is_ a problem with imlib2, and it does cause imlib2 to break with any binutils > .90.x (and there have been like 5 releases since then), and it's nothing to do with debian, I tried an official tarball. I also tried different versions of libtool. The binutils people say it's a problem with imlib2. Recent binutils is more fussy about non-PIC code where it should be PIC (an explicit change they made), and it seems that imlib2's use of loaders (or how it builds them) is buggy. As far as the binutils guys are concerned, imlib2 has been broken all along and it's only being revealed by the latest binutils. I've been looking over it with no joy - could you grab a recent (less than a year old) binutils and take a look please? Tom. -- .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source/UNIX consultant | to...@li... | ^^-^^ `-------------------------------------------------------' |
From: Carsten H. (T. R. <ra...@ra...> - 2001-11-06 23:26:15
|
On Tue, 6 Nov 2001 21:42:59 +0000 Tom Gilbert <to...@li...> babbled profusely: > * Carsten Haitzler (ra...@ra...) wrote: > > On Mon, 5 Nov 2001 05:52:41 +0100 David Odin <di...@wa...> babbled > > profusely: > > > I am becoming completly mad. > > > > > > I'm trying to compile/install all the libs and apps that form e17 from > > > the CVS. > > > > > > I'm using a Potato Debian which has been (succesfully) upgraded to a > > > Woody. So the glibc I'm using is 2.2.4, I guess. > > > > > > Edb compile and install ok. No problem so far. > > > Imlib2 compile and install ok. But from here any program that use the > > > Imlib2 segfault within the dlopen function, trying to load the xpm.so > > > image loader. Note that the imlib2_test program even segfault before > > > main() is called! > > > > > > Can someone help me before I became crazy? > > > > downgrade your gcc/binutils. then it all works happily > > It's just binutils. > > But raster, we do have to fix this. We can't keep telling people to > downgrade. It _is_ a problem with imlib2, and it does cause imlib2 to > break with any binutils > .90.x (and there have been like 5 releases > since then), and it's nothing to do with debian, I tried an official > tarball. I also tried different versions of libtool. libtool does the dynamic loading as such (not imlib2 - it uses libtool) > The binutils people say it's a problem with imlib2. Recent binutils is > more fussy about non-PIC code where it should be PIC (an explicit change > they made), and it seems that imlib2's use of loaders (or how it builds > them) is buggy. As far as the binutils guys are concerned, imlib2 has > been broken all along and it's only being revealed by the latest > binutils. the loaders build with PIC. this is why i can't see the problem.. nor can i help fix it.. as i don't see what fix is needed. output from the building of the loaders: /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -I../libltdl -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include -I. -I.. -I../src -I../loaders -O2 -mpentium -mcpu=pentium -march=pentium -g -W -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -c loader_pnm.c rm -f .libs/loader_pnm.lo gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -I../libltdl -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include -I. -I.. -I../src -I../loaders -O2 -mpentium -mcpu=pentium -march=pentium -g -W -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wp,-MD,.deps/loader_pnm.pp -c loader_pnm.c -fPIC -DPIC -o .libs/loader_pnm.lo notice.. it does compile with PIC. just to be sure i checked imlib2 itself... ahoy: /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -I../libltdl -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include -I. -I.. -I../src -I../loaders -O2 -mpentium -mcpu=pentium -march=pentium -g -W -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -c scale.c mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -I../libltdl -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include -I. -I.. -I../src -I../loaders -O2 -mpentium -mcpu=pentium -march=pentium -g -W -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wp,-MD,.deps/scale.pp -c scale.c -fPIC -DPIC -o .libs/scale.lo again. building with PIC. all libraries should ALWAYS be built with PIC (unless they are .a's - then its not needed) which i've known for years.. and have done. so i'm not sure what i can even do to help here... i'll take a look - but its not the PIC thing at all. > I've been looking over it with no joy - could you grab a recent (less > than a year old) binutils and take a look please? i can.. tho i am not keen on brining my system to a grinding halt :) (according to binutils it requires me to upgrade my libc.. and i dont ever like doing that... recepie for disaster.. here we go... > Tom. > -- > .^. .-------------------------------------------------------. > /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | > /( )\ | Open Source/UNIX consultant | to...@li... | > ^^-^^ `-------------------------------------------------------' > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9362 |
From: Carsten H. (T. R. <ra...@ra...> - 2001-11-06 23:36:27
|
On Tue, 6 Nov 2001 21:42:59 +0000 Tom Gilbert <to...@li...> babbled profusely: > > But raster, we do have to fix this. We can't keep telling people to > downgrade. It _is_ a problem with imlib2, and it does cause imlib2 to > break with any binutils > .90.x (and there have been like 5 releases > since then), and it's nothing to do with debian, I tried an official > tarball. I also tried different versions of libtool. > > The binutils people say it's a problem with imlib2. Recent binutils is > more fussy about non-PIC code where it should be PIC (an explicit change > they made), and it seems that imlib2's use of loaders (or how it builds > them) is buggy. As far as the binutils guys are concerned, imlib2 has > been broken all along and it's only being revealed by the latest > binutils. aah.. in a matter of 30 seconds i've narrowed it... it's the mmx asm - disable mmx and it runs happily.. now what about inlined asm is making binutils severely unhappy (i couldnt even get a backtrace - it was barfing whilst mmaping libc.so.6 - very nasty..) > I've been looking over it with no joy - could you grab a recent (less > than a year old) binutils and take a look please? > > Tom. > -- > .^. .-------------------------------------------------------. > /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | > /( )\ | Open Source/UNIX consultant | to...@li... | > ^^-^^ `-------------------------------------------------------' > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9362 |
From: Carsten H. (T. R. <ra...@ra...> - 2001-11-07 08:09:19
|
On Tue, 6 Nov 2001 21:42:59 +0000 Tom Gilbert <to...@li...> babbled profusely: > It's just binutils. and after some more examination... (gdb) bt #0 0x4000ac69 in _dl_relocate_object () at eval.c:41 #1 0x4013aedd in dl_open_worker (a=0xbffff1f0) at dl-open.c:294 #2 0x4000ce25 in _dl_catch_error () at eval.c:41 #3 0x4013b03e in _dl_open (file=0x80486c4 "/usr/local/lib/libImlib2.so", mode=-2147483391, caller=0x80485a4) at dl-open.c:407 #4 0x40025363 in dlopen_doit (a=0xbffff350) at dlopen.c:39 #5 0x4000ce25 in _dl_catch_error () at eval.c:41 #6 0x400256b6 in _dlerror_run (operate=0x40025338 <dlopen_doit>, args=0xbffff350) at dlerror.c:130 #7 0x40025323 in __dlopen_check ( file=0x80486c4 "/usr/local/lib/libImlib2.so", mode=257) at dlopen.c:53 #8 0x80485a4 in crash () at eval.c:41 #9 0x804865c in main () at eval.c:41 #10 0x40044306 in __libc_start_main (main=0x8048634 <main>, argc=1, ubp_av=0xbffff414, init=0x80483d4 <_init>, fini=0x804869c <_fini>, rtld_fini=0x4000d2cc <_dl_fini>, stack_end=0xbffff40c) at ../sysdeps/generic/libc-start.c:129 i wrote a program that doesnt link to imlib2.. but dlopen()'s and tries to find 1 symbol... this time i can get a bt.. and look where we're segving... _dl_relocate_object () ok.. so now we have even more info. i dont knwo whats makign ti segv.. the ..globl's etc. int he asm are fine.. ive been looking at gcc -S output of code with -fPIC and without -fPIC options... and examining the differences.. the only differences i can see are bits of code that woudl only be reached if the function is actually called.. ld (runtime) is having problems before we ever get this far... so has anyone got suggestions? have u seen this kind of thing before and figure out why and found a cure? anyone? -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9362 |
From: <Val...@vt...> - 2001-11-06 23:43:27
|
On Wed, 07 Nov 2001 10:30:04 +1100, Carsten Haitzler said: > aah.. in a matter of 30 seconds i've narrowed it... it's the mmx asm - disable > mmx and it runs happily.. now what about inlined asm is making binutils severely > unhappy (i couldnt even get a backtrace - it was barfing whilst mmaping > libc.so.6 - very nasty..) Probably an address constant (a pointer to a function or variable). |
From: Carsten H. (T. R. <ra...@ra...> - 2001-11-07 00:05:49
|
On Tue, 06 Nov 2001 18:43:17 -0500 Val...@vt... babbled profusely: > On Wed, 07 Nov 2001 10:30:04 +1100, Carsten Haitzler said: > > > aah.. in a matter of 30 seconds i've narrowed it... it's the mmx asm - > disable > > mmx and it runs happily.. now what about inlined asm is making binutils > severely > > unhappy (i couldnt even get a backtrace - it was barfing whilst mmaping > > libc.so.6 - very nasty..) > > Probably an address constant (a pointer to a function or variable). hmmmmm.... i wonder what it coudl be.. hmmmm -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9362 |
From: Tom G. <to...@li...> - 2001-11-06 23:49:48
|
* Carsten Haitzler (ra...@ra...) wrote: > On Tue, 6 Nov 2001 21:42:59 +0000 Tom Gilbert <to...@li...> babbled > profusely: > > > > > But raster, we do have to fix this. We can't keep telling people to > > downgrade. It _is_ a problem with imlib2, and it does cause imlib2 to > > break with any binutils > .90.x (and there have been like 5 releases > > since then), and it's nothing to do with debian, I tried an official > > tarball. I also tried different versions of libtool. > > > > The binutils people say it's a problem with imlib2. Recent binutils is > > more fussy about non-PIC code where it should be PIC (an explicit change > > they made), and it seems that imlib2's use of loaders (or how it builds > > them) is buggy. As far as the binutils guys are concerned, imlib2 has > > been broken all along and it's only being revealed by the latest > > binutils. > > aah.. in a matter of 30 seconds i've narrowed it... it's the mmx asm - disable > mmx and it runs happily.. now what about inlined asm is making binutils severely > unhappy (i couldnt even get a backtrace - it was barfing whilst mmaping > libc.so.6 - very nasty..) See? I knew you'd be better at finding this bug than me :) I never even looked at the .S files :) Tom. -- .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source/UNIX consultant | to...@li... | ^^-^^ `-------------------------------------------------------' |
From: Carsten H. (T. R. <ra...@ra...> - 2001-11-07 00:05:49
|
On Tue, 6 Nov 2001 23:49:41 +0000 Tom Gilbert <to...@li...> babbled profusely: > * Carsten Haitzler (ra...@ra...) wrote: > > On Tue, 6 Nov 2001 21:42:59 +0000 Tom Gilbert <to...@li...> babbled > > profusely: > > > > > > > > But raster, we do have to fix this. We can't keep telling people to > > > downgrade. It _is_ a problem with imlib2, and it does cause imlib2 to > > > break with any binutils > .90.x (and there have been like 5 releases > > > since then), and it's nothing to do with debian, I tried an official > > > tarball. I also tried different versions of libtool. > > > > > > The binutils people say it's a problem with imlib2. Recent binutils is > > > more fussy about non-PIC code where it should be PIC (an explicit change > > > they made), and it seems that imlib2's use of loaders (or how it builds > > > them) is buggy. As far as the binutils guys are concerned, imlib2 has > > > been broken all along and it's only being revealed by the latest > > > binutils. > > > > aah.. in a matter of 30 seconds i've narrowed it... it's the mmx asm - > disable > > mmx and it runs happily.. now what about inlined asm is making binutils > severely > > unhappy (i couldnt even get a backtrace - it was barfing whilst mmaping > > libc.so.6 - very nasty..) > > See? I knew you'd be better at finding this bug than me :) heheheh :) but we have now 2 solutions.. --disable-mmx (and get a quite beefy slowdown) or downgrade binutils :) > I never even looked at the .S files :) i'm looking right now.. > Tom. > -- > .^. .-------------------------------------------------------. > /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | > /( )\ | Open Source/UNIX consultant | to...@li... | > ^^-^^ `-------------------------------------------------------' > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9362 |
From: Christian K. <kre...@in...> - 2001-11-07 09:08:33
|
"Carsten Haitzler (The Rasterman)" wrote: > > On Tue, 6 Nov 2001 21:42:59 +0000 Tom Gilbert <to...@li...> babbled > profusely: > > > It's just binutils. > > and after some more examination... > > (gdb) bt > #0 0x4000ac69 in _dl_relocate_object () at eval.c:41 > #1 0x4013aedd in dl_open_worker (a=0xbffff1f0) at dl-open.c:294 > #2 0x4000ce25 in _dl_catch_error () at eval.c:41 > #3 0x4013b03e in _dl_open (file=0x80486c4 "/usr/local/lib/libImlib2.so", > mode=-2147483391, caller=0x80485a4) at dl-open.c:407 > #4 0x40025363 in dlopen_doit (a=0xbffff350) at dlopen.c:39 > #5 0x4000ce25 in _dl_catch_error () at eval.c:41 > #6 0x400256b6 in _dlerror_run (operate=0x40025338 <dlopen_doit>, > args=0xbffff350) at dlerror.c:130 > #7 0x40025323 in __dlopen_check ( > file=0x80486c4 "/usr/local/lib/libImlib2.so", mode=257) at dlopen.c:53 > #8 0x80485a4 in crash () at eval.c:41 > #9 0x804865c in main () at eval.c:41 > #10 0x40044306 in __libc_start_main (main=0x8048634 <main>, argc=1, > ubp_av=0xbffff414, init=0x80483d4 <_init>, fini=0x804869c <_fini>, > rtld_fini=0x4000d2cc <_dl_fini>, stack_end=0xbffff40c) > at ../sysdeps/generic/libc-start.c:129 > > i wrote a program that doesnt link to imlib2.. but dlopen()'s and tries to find > 1 symbol... this time i can get a bt.. and look where we're segving... > _dl_relocate_object () Raster, could you post that program? What mmx code is in it? > ok.. so now we have even more info. i dont knwo whats makign ti segv.. the > ..globl's etc. int he asm are fine.. ive been looking at gcc -S output of code > with -fPIC and without -fPIC options... and examining the differences.. the only > differences i can see are bits of code that woudl only be reached if the > function is actually called.. ld (runtime) is having problems before we ever get > this far... Cheers, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Carsten H. (T. R. <ra...@ra...> - 2001-11-07 10:33:03
|
On Wed, 07 Nov 2001 10:08:46 +0100 Christian Kreibich <kre...@in...> babbled profusely: > > > "Carsten Haitzler (The Rasterman)" wrote: > > > > On Tue, 6 Nov 2001 21:42:59 +0000 Tom Gilbert <to...@li...> babbled > > profusely: > > > > > It's just binutils. > > > > and after some more examination... > > > > (gdb) bt > > #0 0x4000ac69 in _dl_relocate_object () at eval.c:41 > > #1 0x4013aedd in dl_open_worker (a=0xbffff1f0) at dl-open.c:294 > > #2 0x4000ce25 in _dl_catch_error () at eval.c:41 > > #3 0x4013b03e in _dl_open (file=0x80486c4 "/usr/local/lib/libImlib2.so", > > mode=-2147483391, caller=0x80485a4) at dl-open.c:407 > > #4 0x40025363 in dlopen_doit (a=0xbffff350) at dlopen.c:39 > > #5 0x4000ce25 in _dl_catch_error () at eval.c:41 > > #6 0x400256b6 in _dlerror_run (operate=0x40025338 <dlopen_doit>, > > args=0xbffff350) at dlerror.c:130 > > #7 0x40025323 in __dlopen_check ( > > file=0x80486c4 "/usr/local/lib/libImlib2.so", mode=257) at dlopen.c:53 > > #8 0x80485a4 in crash () at eval.c:41 > > #9 0x804865c in main () at eval.c:41 > > #10 0x40044306 in __libc_start_main (main=0x8048634 <main>, argc=1, > > ubp_av=0xbffff414, init=0x80483d4 <_init>, fini=0x804869c <_fini>, > > rtld_fini=0x4000d2cc <_dl_fini>, stack_end=0xbffff40c) > > at ../sysdeps/generic/libc-start.c:129 > > > > i wrote a program that doesnt link to imlib2.. but dlopen()'s and tries to > find > > 1 symbol... this time i can get a bt.. and look where we're segving... > > _dl_relocate_object () > > Raster, could you post that program? What mmx code is in it? it's the mmx in imlib2 #include <stdio.h> #include <X11/Xlib.h> #include <Imlib2.h> #include <stdlib.h> #include <unistd.h> #include <dlfcn.h> void crash(void) { void *handle; void (*imlib_context_set_image) (void *im); #if 0 handle = dlopen("/usr/local/lib/libImlib2.so", RTLD_NOW); handle = dlopen("/usr/local/lib/libImlib2.so", RTLD_LAZY); handle = dlopen("/usr/local/lib/libImlib2.so", RTLD_NOW | RTLD_GLOBAL); handle = dlopen("/usr/local/lib/libImlib2.so", RTLD_LAZY | RTLD_GLOBAL); #endif handle = dlopen("/usr/local/lib/libImlib2.so", RTLD_LAZY | RTLD_GLOBAL); if (!handle) { printf("ERROR: %s\n", dlerror()); exit(0); } imlib_context_set_image = dlsym(handle, "imlib_context_set_image"); if (!imlib_context_set_image) { printf("ERROR: %s\n", dlerror()); exit(0); } imlib_context_set_image(NULL); } int main (int argc, char **argv) { printf("ok lets try this...\n"); sleep(2); crash(); } compile: gcc crash.c -o crash -ldl -g `imlib2-config --cflags` > > > ok.. so now we have even more info. i dont knwo whats makign ti segv.. the > > ..globl's etc. int he asm are fine.. ive been looking at gcc -S output of > code > > with -fPIC and without -fPIC options... and examining the differences.. the > only > > differences i can see are bits of code that woudl only be reached if the > > function is actually called.. ld (runtime) is having problems before we ever > get > > this far... > > Cheers, > -- Christian. > ________________________________________________________________________ > http://www.whoop.org > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9362 |
From: Tom G. <to...@li...> - 2001-11-05 18:54:23
|
* David Odin (di...@wa...) wrote: > Hi, > > I am becoming completly mad. > > I'm trying to compile/install all the libs and apps that form e17 from > the CVS. > > I'm using a Potato Debian which has been (succesfully) upgraded to a > Woody. So the glibc I'm using is 2.2.4, I guess. > > Edb compile and install ok. No problem so far. > Imlib2 compile and install ok. But from here any program that use the > Imlib2 segfault within the dlopen function, trying to load the xpm.so > image loader. Note that the imlib2_test program even segfault before > main() is called! > > Can someone help me before I became crazy? Downgrade your binutils at least one major version until we work out what imlib2 is doing to piss off the newer binutils. Tom. -- .^. .-------------------------------------------------------. /V\ | Tom Gilbert, London, England | http://linuxbrit.co.uk | /( )\ | Open Source/UNIX consultant | to...@li... | ^^-^^ `-------------------------------------------------------' |
From: David O. <di...@wa...> - 2001-11-06 14:37:59
|
On Mon, Nov 05, 2001 at 06:54:12PM +0000, Tom Gilbert wrote: > * David Odin (di...@wa...) wrote: > > Hi, > > > > I am becoming completly mad. > > > > I'm trying to compile/install all the libs and apps that form e17 from > > the CVS. > > > > I'm using a Potato Debian which has been (succesfully) upgraded to a > > Woody. So the glibc I'm using is 2.2.4, I guess. > > > > Edb compile and install ok. No problem so far. > > Imlib2 compile and install ok. But from here any program that use the > > Imlib2 segfault within the dlopen function, trying to load the xpm.so > > image loader. Note that the imlib2_test program even segfault before > > main() is called! > > > > Can someone help me before I became crazy? > > Downgrade your binutils at least one major version until we work out > what imlib2 is doing to piss off the newer binutils. > Thanks. That was it. FYI, glib-2.0 (CVS) also plays with dlopen() functions (but not with libtool ltdl), and works OK with any binutils I've tried. So now I can compile and use any libs in e17/libs. Thanks for this. Unfortunately, I cannot go really further. The compilation of fam stops in BTree.h (I can give you the error messages if you want). Which compiler/binutils/libstdc++-dev do I need to compile it, or is there a .deb package of fam for woody? Thanks, DindinX -- di...@wa... Charity, n.: A thing that begins at home and usually stays there. |
From: <s.k...@t-...> - 2001-11-06 15:21:18
|
On Tue, 6 Nov 2001 15:36:44 +0100 David Odin <di...@wa...> wrote: > Unfortunately, I cannot go really further. The compilation of fam > stops in BTree.h (I can give you the error messages if you want). > Which compiler/binutils/libstdc++-dev do I need to compile it, or is > there a .deb package of fam for woody? You have to add "#include <stdlib.h>" to BTree.h At least that's how it worked for me. Cheers, Sebastian |
From: David O. <di...@wa...> - 2001-11-06 15:36:36
|
On Tue, Nov 06, 2001 at 05:20:35PM +0100, Sebastian Kwiatkowski wrote: > On Tue, 6 Nov 2001 15:36:44 +0100 > David Odin <di...@wa...> wrote: > > > Unfortunately, I cannot go really further. The compilation of fam > > stops in BTree.h (I can give you the error messages if you want). > > Which compiler/binutils/libstdc++-dev do I need to compile it, or is > > there a .deb package of fam for woody? > > You have to add "#include <stdlib.h>" to BTree.h > At least that's how it worked for me. > Yes. I've noticed this. And this fix the problem of using 'NULL' without declaring it. I also had some other errors, due to some C++ nastiness. I'll retry this night. Thanks, DindinX -- di...@wa... When you're dining out and you suspect something's wrong, you're probably right. |
From: Christian K. <kre...@in...> - 2001-11-06 15:50:44
|
David Odin wrote: > > Yes. I've noticed this. And this fix the problem of using 'NULL' > without declaring it. I also had some other errors, due to some C++ > nastiness. I'll retry this night. I'd like to see those errors, please. Thanks, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: David O. <di...@wa...> - 2001-11-06 20:39:38
|
On Tue, Nov 06, 2001 at 04:50:45PM +0100, Christian Kreibich wrote: > > David Odin wrote: > > > > Yes. I've noticed this. And this fix the problem of using 'NULL' > > without declaring it. I also had some other errors, due to some C++ > > nastiness. I'll retry this night. > > I'd like to see those errors, please. > Oops, sorry. I certainly had corrupt the BTree.h file myself. I've successfully compiled fam, using the archive provided on the enlightenment web site. I'm now starting to use e17. :-) It's fun but I'm unable to move, iconify or maximize a window. Sorry, DindinX -- di...@wa... I hate quotations. Tell me what you know. -- Ralph Waldo Emerson, "Journal", May 1849 |
From: Christian K. <kre...@in...> - 2001-11-06 22:18:21
|
David Odin wrote: > > I'm now starting to use e17. :-) It's fun but I'm unable to move, > iconify or maximize a window. I see that sometimes when I open a directory, but I have so far not been able to reproduce it. It's definitely not deterministic over here, though, and works most of the time. > Sorry, What for? We're sorry if our code doesn't work :) -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Christian K. <kre...@in...> - 2001-11-06 15:32:38
|
David Odin wrote > > Unfortunately, I cannot go really further. The compilation of fam > stops in BTree.h (I can give you the error messages if you want). > Which compiler/binutils/libstdc++-dev do I need to compile it, or is > there a .deb package of fam for woody? FAQ - check the website :) -- Christian. ________________________________________________________________________ http://www.whoop.org |