Bug 690296 - segmentation fault on devs.tr while compiling in shared mode
Summary: segmentation fault on devs.tr while compiling in shared mode
Status: RESOLVED DUPLICATE of bug 691264
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Config/Install (show other bugs)
Version: 8.64
Hardware: PC Linux
: P4 normal
Assignee: Ralph Giles
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-19 14:21 UTC by Maciej Pilichowski
Modified: 2010-05-02 12:38 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2009-02-19 14:21:16 UTC
segmentation fault on devs.tr while compiling in shared mode

I have to install GS from sources and the normal installation works perfectly. 
But since I need to build also libraries for ImageMagick I need shared build. 
So I followed the manual however in this case I get segmentation fault right 
after executing make:

make LDFLAGS=' -shared -Wl,-soname=libgs.so.8' 
GS_XE=./bin/../sobin/libgs.so.8.64 STDIO_IMPLEMENTATION=c 
DISPLAY_DEV=./obj/../soobj/display.dev BINDIR=./bin/../sobin 
GLGENDIR=./obj/../soobj GLOBJDIR=./obj/../soobj PSGENDIR=./obj/../soobj 
PSOBJDIR=./obj/../soobj 
CFLAGS='-O2 -fPIC -shared -Wall -Wstrict-prototypes -Wmissing-declarations -Wmissing-prototypes -fno-builtin -fno-common -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/local/lib/ghostscript/8.64\"' 
prefix=/usr/local ./bin/../sobin/gsc ./bin/../sobin/gsx
make[1]: Entering directory `/home/macias/rpm/BUILD/ghostscript-8.64'
./obj/../soobj/echogs -w ./obj/../soobj/devs.tr - -include ./obj/../soobj/unix_
make[1]: *** [obj/../soobj/devs.tr] Segmentation fault

x86_64, opensuse 11.1, gcc-4.3-34.243, GS 8.64.
Comment 1 Ralph Giles 2009-02-19 14:31:45 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.
Comment 2 Maciej Pilichowski 2009-02-20 00:36:30 UTC
> 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)
Comment 3 Ralph Giles 2009-02-20 14:16:16 UTC
Yeah, not so useful. Can you try reproducing with a debug version?
Comment 4 Maciej Pilichowski 2009-02-21 00:53:59 UTC
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.
Comment 5 Ralph Giles 2009-02-21 10:59:57 UTC
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.
Comment 6 Maciej Pilichowski 2009-02-21 12:13:41 UTC
> 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
Comment 7 Maciej Pilichowski 2009-02-26 12:57:54 UTC
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.
Comment 8 Hin-Tak Leung 2010-05-02 02:50:04 UTC
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.
Comment 9 Maciej Pilichowski 2010-05-02 06:17:03 UTC
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?
Comment 10 Hin-Tak Leung 2010-05-02 09:49:20 UTC
(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 ***
Comment 11 Maciej Pilichowski 2010-05-02 12:38:53 UTC
> 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.