Finally I managed to find the bug...
The problem was that when I was trying to build the final executable
the Makefile was passing option -static to ld.
This option does not exist in the man page...
When I was using that same Makefile with OSF1/v2.0 the loader
was ignoring the option and everything was fine.
But for OSF1/v3.0 things have changed..
Now the option is again accepted but with unpredictable(!) results.
( Segmentation fault. Core dumped ).
Seems that is not obvious for some people to do option parsing !!!
Or may be I am missing some "undocumented feautures"....
In any case , thanks go to all of you that responded to my question.
Kosmas Papachristos.
----------
Brad Daniels <daniels_at_biles.com> writes:
>I had similar problems a while back. It seems that ld does some kind of deep
>recursion, effectively putting a lot of its symbolic info on the stack. The
>default max. stack size of 32MB is not sufficient when you're linking more
>than about 50 MB of object files (exact mileage on that will probably vary.)
>Bump up your kernel's dflssiz and maxssiz parameters to something large. I
>ended up setting mine at around 256MB. Note that dflssiz is the "default
>maximum" stack size, not the default stack size. It's really a bit silly,
>since you still have to set your shell's stack size limit using ulimit.
>I really think they could have done something more useful with the parameters,
> but...
Dr. Tom Blinn <tpb_at_zk3.dec.com> writes:
>Do you have a support contract with Digital? Have you contacted your
>Digital Service support person?
>
>Even if you do get a patch, it might be bogus. The ONLY valid source for
>patched software is directly from Digital.
>
>We have started shipping DEC OSF/1 V3.2 world-wide today, but I don't know
>that it has any fixed 'ld'.
>
>You might try reverting just 'ld' to the one from V2.0 and see if that is a
>solution to the problem.
>
>
>Tom
mjr_at_zk3.dec.com writes:
>There are no known additional problems to cause ld to core
>dump in V3.0.
>
>My guess is that some file is corrupted that now shows up in
>the V3.0 linker. The way to find out is to pass -v to 'ld'. It
>will list the files as it's processing them, and the one that core
>dumps is the problem.
>
>I don't know how you're linking. If you're calling 'ld' directly,
>then just add -v. If you're using 'cc' to do the link, then add
>"-Wl,-v" to the 'cc' line.
>
>Then try rebuilding the file it's complaining on.
>
>I really can't do anything else for you without have access to the files
>to perform a link.
>
>-mike
Steve Gibbons <steve_at_aztech.com> writes:
>Have you tried combining your multitude of .o files into a .a ?
>
>--
>Steve_at_AZTech.Com
Received on Wed Feb 22 1995 - 06:16:23 NZDT