https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
> (In reply to Rainer Orth from comment #0)
[...]
>> *
>>
>> symbol not found: dl_iterate_phdr
>> (libdruntime/.libs/libgdruntime.so)
>>
>> Unlike Solaris 11, dl_iterate_phdr support was only backported to a late
>> Solaris 10 update and even so only lives in libdl, not in libc. Not yet
>> fixed.
>>
>
> So does dlopen and dl_iterate_phdr live in separate libraries? I would have
In Solaris 10, dlopen lives in libc, but is just a filter on ld.so.1
(the runtime linker), while dl_iterate_phdr only exists in libdl.so.1.
In Solaris 11, OTOH, both exist in libc as filter on ld.so.1.
> thought that DRUNTIME_LIBRARIES_DLOPEN would correctly add -ldl to the driver
> spec file.
Since no separate library is needed for dlopen, -ldl isn't added to $LIBS.
This could certainly be fixed by augmenting the autoconf test.
>> *
>>
>> symbol not found: getprogname
>> (libdruntime/.libs/libgdruntime.so)
>>
>> Solaris 10 lacks getprogname or equivalent; for now I'm faking this by just
>> returning "a.out".
>>
>
> There's the following function in rt/dmain2.d
>
> extern (C) string[] rt_args();
>
> Would the basename() of argv[0] be a suitable fallback? Looking at illumos,
Sure. As an initial hack, I even used a hardcoded "a.out".
> they use dlinfo(RTLD_SELF, RTLD_DI_ARGSINFO) and strrchr(argv0, '/').
True, and that dlinfo request already exists in Solaris 10.
>> *
>> symbol not found: posix_memalign
>> (src/.libs/libgphobos.so)
>>
>> Also missing from Solaris 10. I've not yet checked what to do here. One
>> might be able to use pagealign_alloc from gnulib instead?
>
> If the OS version can be obtained from the compiler, same as FBSD_MAJOR, then
Right now, it can't. However, the Studio compilers predefine
__SunOS_RELEASE, and gcc could be changed to mimic that. Of course, the
test could always be made in configure one way or the other and the
outcome used in libdruntime, similarly to OS_Have_Dlpi_Tls_Modid.
> one option would be to provide posix_memalign internally in druntime.
>
> extern(D) int posix_memalign(void** ptr, size_t alignment, size_t size)
> {
> // ...
> }
>
> extern(D) so that it won't conflict with extern(C) function of the same name.
>
> Though whether it is worth the effort, I'm not so sure. As you've said that
> Solaris10 will be removed before.
Exactly: I've had a look at the open issues on Solaris 10. The ones
above can certainly be worked around or avoided some way or another, but
there's a showstopper, I believe: the 64-bit x86 problem worked around
by ld -z relax=transtls also exists on Solaris 10, but the workaround
does not. This means that we're either left with a 32-bit-only Solaris
10/x86 port or one that is only usable with gld. While Solaris 10/SPARC
wouldn't be affected, SPARC is in considerably worse shape right now,
and I'm pretty certain our time would be far better spent fixing Solaris
11 issues: this will benefit way more users. I doubt there are many
considering upgrading to gcc 9 on Solaris 10, let alone trying a new
language.
My suggestion would be to close the PR as WONTFIX. Should there really
be demand, one could still apply Solaris 10 fixes to the GCC 9 branch
after the 9.1.0 release: there's considerable leeway for changes like
this and a new language.
