Mailing List Archive

> From: Don Lewis <gdonl@gv.ssi1.com>
>
> We recently ran into a problem here with our SunOS 4.1.x machines. We
> rebuilt our shared libc.so to include the DNS resolver routines, and
> we neglected to create the matching libc.sa file. A bunch of executables
> were linked against the new library, and although the SunOS AnswerBook
> says this may cause a performance degradation, it actually appears to
> tickle a kernel bug which causes the machine to hang after running for
> a week to a month.
>
> Since discovering this, I've gotten rather paranoid about breaking any of
> the shared library rules, so I tried building perl with lddlflags set to
> "-assert nodefinitions -assert pure-text". This caused the ODBM_File and
> POSIX extension libraries to fail to build, because the libdbm.a and
> libposix.a libraries that are linked into these extensions are not position
> independent.

I don't think this is the same situation as a .so without a matching .sa.
But I may be wrong.

Tim.

In <199509240243.TAA05188@sunrise.gv.ssi1.com>
On Sat, 23 Sep 1995 19:43:32 -0700 (PDT)
Don Lewis <gdonl@gv.ssi1.com> writes:
>
>Since discovering this, I've gotten rather paranoid about breaking any of
>the shared library rules, so I tried building perl with lddlflags set to
>"-assert nodefinitions -assert pure-text".

>I have not yet come up with
>a fix for the Tk extension, which is linked against the non-PIC libm.a.

I have a freely-distributable libm - I think it came from Sun.
You could compile that -PIC and link to Tk.
You would loose some architecture dependant optimizations I guess.

>
>There is also a potential problem with exported initialized data in
>these extension libraries.

I think this fixed for core Tk by 4.1a1 which is now out. Microsoft's DLLs
can't do exported data at all.

On Sep 25, 8:58am, Nick.Ing-Simmons@tiuk.ti.com wrote:
} Subject: Re: dynamically loaded extensions under SunOS
} In <199509240243.TAA05188@sunrise.gv.ssi1.com>
} On Sat, 23 Sep 1995 19:43:32 -0700 (PDT)
} Don Lewis <gdonl@gv.ssi1.com> writes:
} >
} >Since discovering this, I've gotten rather paranoid about breaking any of
} >the shared library rules, so I tried building perl with lddlflags set to
} >"-assert nodefinitions -assert pure-text".
}
} >I have not yet come up with
} >a fix for the Tk extension, which is linked against the non-PIC libm.a.
}
} I have a freely-distributable libm - I think it came from Sun.
} You could compile that -PIC and link to Tk.
} You would loose some architecture dependant optimizations I guess.

That should work. Another approach would be to explode all the system
supplied .a files that don't have PIC equivalents and statically link
the .o files into the base executable. You can then leave off these
libraries when linking the .so files for the extensions.

} >There is also a potential problem with exported initialized data in
} >these extension libraries.
}
} I think this fixed for core Tk by 4.1a1 which is now out. Microsoft's DLLs
} can't do exported data at all.

Some of the other extensions have exported initialized data:
DB_File:
__default_hash
ODBM_File:
hitab
hltab
POSIX:
fp_pi
tzname
SDBM_File:
nullitem

--- Truck

On Sep 25, 11:12am, Tim Bunce wrote:
} Subject: Re: dynamically loaded extensions under SunOS
}
} > From: Don Lewis <gdonl@gv.ssi1.com>
} >
} > We recently ran into a problem here with our SunOS 4.1.x machines. We
} > rebuilt our shared libc.so to include the DNS resolver routines, and
} > we neglected to create the matching libc.sa file. A bunch of executables
} > were linked against the new library, and although the SunOS AnswerBook
} > says this may cause a performance degradation, it actually appears to
} > tickle a kernel bug which causes the machine to hang after running for
} > a week to a month.
} >
} > Since discovering this, I've gotten rather paranoid about breaking any of
} > the shared library rules, so I tried building perl with lddlflags set to
} > "-assert nodefinitions -assert pure-text". This caused the ODBM_File and
} > POSIX extension libraries to fail to build, because the libdbm.a and
} > libposix.a libraries that are linked into these extensions are not position
} > independent.
}
} I don't think this is the same situation as a .so without a matching .sa.
} But I may be wrong.

I wouldn't be too sure. Both would seem to involve copy-on-write of
pages mapped in from the .so file. My theory on the bug is that this
causes the kernal to leak memory pages. When it leaks enough, it hangs.

In any case all the non-PIC stuff in the .so file would not be shareable
between processes.

--- Truck