Re: z/OS and libc
[email protected] (Jarkko Hietaniemi) Tue, 6 Oct 2015 21:26:31 -0400
| Newsgroups | perl.mvs,perl.perl5.porters |
|---|---|
| Message-ID | <[email protected]> |
On Tuesday-201510-06 20:45, Karl Williamson wrote: > I'm working on continuing to port perl5 to z/OS. One test that is > failing is beyond my knowledge level. The Dynaloader module has a > function dl_findfile() which looks for libraries in the path. It is > expecting to find libc at least, but is finding nothing. > > This test does not work on several platforms, even some Unix-like ones, > and my guess is it doesn't work on z/OS either. But I am hoping someone > can give me more information. > > One of the comments in the perl source says: > # On OS/390, libc.a doesn't really hold anything at all, This does not necessarily mean much, without knowing more details. Taken literally it means "the file called libc.a holds nothing", which may or may not be relevant to what dl_findfile() tries to do. Because: the ".a" *usually* means in UNIX parlance a static archive of code, as opposed to dynamic library (which would most often have .so). And since DynaLoader is about dynamic/runtime loading, the .a might be irrelevant. That being said... whether .a in z/OS means static or dynamic, or anything at all, I don't know for certain, but reading hints/os390.sh makes me think .a actually is what .so is elsewhere. From quick reading the dl_findfile() is trying to find the "libc", the central library of UNIX, which again I don't know whether/where it exists in z/OS. It may be available in static and dynamic flavors, but for DynaLoader only the latter should matter. But putting together .a == .so and "libc" is empty... so maybe the dl_findfile() failing is correct? But then again... reading ext/DynaLoader/DynaLoader_pm.PL... it is such a forest of operating system specific "ifdefs"... so maybe it just needs some z/OS-specific love? Could we see the extracted ext/DynaLoader/DynaLoader.pm? Sorry, no immediate answer to your query. > And that makes me think that looking for it (and perhaps any Unix-y > library) is futile. >