Dagobert Michelsen <d...@opencsw.org> writes:
> Am 19.02.2015 um 05:02 schrieb Daiki Ueno <u...@gnu.org>:
>> Dagobert Michelsen <d...@opencsw.org> writes:
>>> FAIL: lang-vala
>>> ===============
>>>
>>> ld.so.1: prog: fatal: libintl.so.8: open failed: No such file or directory
>>> ./lang-vala: line 90: 29632 Killed LANGUAGE= LC_ALL=$LOCALE_FR
>>> ./prog > prog.out
>>> FAIL lang-vala (exit status: 1)
>>
>> Vala is basically a C translator and it takes compiler/linker flags from
>> pkgconfig. So I suspect your glib-2.0.pc does not point to the correct
>> location of the system's libintl library. You could try adding
>> --verbose to ${VALAC} command line in lang-vala to get the actual linker
>> command line (maybe we should add it by default for better diagnostics).
>
> I finally managed to isolate the issue. Here is my testcase:
Thanks.
> When I use
> PATH=/opt/csw/bin:/usr/bin
> then pkg-config from OpenCSW takes precedence and glib-2.0.pc is taken from
> OpenCSW which requires libintl.so.8 and marks it as NEEDED in the resulting
> binary.
It sounds to me as if valac is not working out of box on the OpenCSW
environment, since every vala program needs to be compiled with the
-R/opt/csw/lib setting.
> I do pass LDFLAGS=-R/opt/csw/lib during configure-time but that doesn’t seem
> to be
> sufficient. Is this intended or should the tests take LDFLAGS into account?
Unfortunately, this is not easily possible. To pass LDFLAGS to the
linker, we would need to split the compilation phase into two i.e.,
compile and link. In the link phase, we need to get other linker flags
from glib-2.0.pc, but it is an implementation detail of valac, and IMO
we shouldn't rely on that.
By the way, I tend to think those lang-* tests might be pointless, since
they check the system, not the gettext package itself. Perhaps it might
be better to disable them by default.
Regards,
--
Daiki Ueno
