Summary: | segmentation fault on devs.tr while compiling in shared mode | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Maciej Pilichowski <bluedzins> |
Component: | Config/Install | Assignee: | Ralph Giles <ralph.giles> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | P4 | ||
Version: | 8.64 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- |
Description
Maciej Pilichowski
2009-02-19 14:21:16 UTC
can you confirm the echogs command segfaults on its own? $ ./soobj/echogs -w ./soobj/devs.tr - -include ./soobj/unix_ If that fails, please try: $ gdb --args ./soobj/echogs -w ./soobj/devs.tr - -include ./soobj/unix_ (gdb) run ... (gdb) bt and paste the output. > can you confirm the echogs command > segfaults on its own? Yes. > (gdb) bt > and paste the output. I hope this is helpful, because I've never seen so tiny log. (gdb) run Starting program: /home/macias/rpm/BUILD/ghostscript-8.64/soobj/echogs -w ./soobj/devs.tr - -include ./soobj/unix_ Program received signal SIGSEGV, Segmentation fault. 0x0000000000000006 in ?? () (gdb) bt #0 0x0000000000000006 in ?? () #1 0x00007fffffffe001 in ?? () #2 0x00007fffffffe036 in ?? () #3 0x00007fffffffe039 in ?? () #4 0x00007fffffffe049 in ?? () #5 0x00007fffffffe04b in ?? () #6 0x00007fffffffe054 in ?? () #7 0x0000000000000000 in ?? () (gdb) Yeah, not so useful. Can you try reproducing with a debug version? You mean I should configure GS with --enable-debug and then repeat the steps? The result is exactly the same. Btw. maybe this is just stupid comment, but you know that Makefile is created according to configure, but unix-gcc.mak is not -- so it does not know anything about --enable-debug and thus the build is exactly the same. I tried to force debug mode by running DEBUG=1 make so but with no effect. Ah, looks like the -g from --enable-debug isn't propagated to the so target. Try 'make sodebug'. You're correct that configure doesn't touch unix-gcc.mak. That's an alternate, deprecated, top-level makefile. > Try 'make sodebug'.
> You're correct that configure doesn't touch unix-gcc.mak. That's an
> alternate, deprecated, top-level makefile.
You mean unix-gcc.mak is deprecated? I used it only because the manual says,
that I should use it :-).
Since I am not sure which makefile is "good" one, I used both. So when using
unix-gcc.mak (as toplevel makefile of course) despite sodebug I get exactly the
same log as before. However something is wrong here because unix-gcc.mak does
not have such entry as "sodebug".
Using toplevel Makefile compiling now does not crash, it works for pretty some
time, but at the end I get this:
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: ./obj/../soobj/gs.o:
relocation R_X86_64_32 against `a local symbol' can not be used when making a
shared object; recompile with -fPIC
./obj/../soobj/gs.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
I am not sure if I did well or wrong, but at least I installed GS. 1) I configured GS explicitly stating the libs should go to /usr/local/lib64 because despite my machine is 64bit GS configure builds Makefile in such way the libs go to /usr/local/lib (i.e. 32-bit) 2) I ignored GS manual and did not link unix-gcc.mak as makefile 3) I edited Makefile manually to remove XCFLAGS because despite the comment XCFLAGS can be passed from commandline it is impossible when this flag is cleared in the script 4) I run: XCGLAGS=-fPIC make so So, if my steps were correct there are 3-4 missing pieces in GS installation procedure. Please do not override LDFLAGS/CFLAGS without understanding what you are doing. In particular, adding "-shared" is wrong. (./configure already adds it to the right place, and *only* the right place). See also my comment http://bugs.ghostscript.com/show_bug.cgi?id=691262#c1 and the surrounding threads. There is such thing as program manual. So I followed the instructions and get segfault -- it is hardly INVALID case (reopening). If you know what should be changed, then please fix the manual, but do not close the report because it does not improve anything, does it? (In reply to comment #9) > There is such thing as program manual. So I followed the instructions and get > segfault -- it is hardly INVALID case (reopening). If you know what should be > changed, then please fix the manual, but do not close the report because it > does not improve anything, does it? THere is already another bug for fixing the manual - bug 691264 , if that makes you happier. *** This bug has been marked as a duplicate of bug 691264 *** > THere is already another bug for fixing the manual
Already? :-) Good one, anyway if your duplicate of my report will cause improvement of GS, I am happy.
|