Re: Solaris build (was: suggestion for adding sdk/lib to pluginapp.bin or libuno_sal.so symlink in ure/lib)

On 23/05/14 08:59, Richard PALO wrote:
> Le 21/05/14 10:56, Stephan Bergmann a écrit :
> > On 05/21/2014 07:13 AM, Richard PALO wrote:

> > > Either 'sdk/lib' needs to be added as a runpath-link (which works fine
> > > manually) or a symlink to libuno_sal.so.3 would need to be created in
> > > 'ure/lib' as that path is already used.
> >
> > -L$I/sdk/lib should be on the above command line (and is on Linux) via
> > -L$(INSTDIR)/$(SDKDIRNAME)/lib in the definition of
> > gb_LinkTarget_get_linksearchpath_for_layer in
> > solenv/gbuild/platform/com_GCC_class.mk.  No idea why that does not work
> > for you on SunOS.
> >
> > Stephan
> Hi,
> Thanks for the pointer, and yes this file is included in solaris.mk as 
> it is in unxgcc.mk...
>
> So, I was curious to notice that nsplugin seemed to work, and in 
> comparing the two mk files the following extract from 
> Executable_pluginapp.bin.mk is the only pertinent difference:
> > # the orignal dmakefile said: don't ask, it's ugly
> > ifeq ($(OS),SOLARIS)
> > $(eval $(call gb_Executable_set_ldflags,pluginapp.bin,\
> >      -z nodefs \
> > ))
> > endif
>
> when I look into gb_Executable_set_ldflags, the problem is in LinkTarget.mk:

yes, that looks clearly wrong, when using "set" functions (of which
set_ldflags may well be the only one by now, due to their error-prone
nature) you have to add the target local variable as well, as in:

> $(eval $(call gb_Executable_set_ldflags,pluginapp.bin,\
>       $(T_LDFLAGS) \
>       -z nodefs \
> ))

> > # call gb_LinkTarget_add_ldflags,linktarget,ldflags
> > define gb_LinkTarget_add_ldflags
> > $(call gb_LinkTarget_get_target,$(1)) : T_LDFLAGS += $(2)
> >
> > endef

or alternatively use gb_Executable_add_ldflags, which appends to the
existing variable and is thus much easier to use.

> In summary, the following patch to Executable_pluginapp.bin.mk seems to 
> build for now (the first part is because motif is, well...:-):

apparently the idea there was to always use Motif on Solaris, and the
only use of it is:

plugcon.hxx:

> #if defined SOLARIS
> #    define USE_MOTIF
> #endif

> #if defined USE_MOTIF
> #include <Xm/DrawingA.h>
> #else

npwrap.cxx:

> #if defined USE_MOTIF
>           "drawingArea",
>         xmDrawingAreaWidgetClass,
> #else
>         "",
>         compositeWidgetClass,
> #endif

if you say that Motif shouldn't be used (and AFAIK you're one of only 2
people that build on Solaris) then we should just remove all of that;
likely nobody here knows why it was needed in the past.

you can mail a patch to the list, or you can submit it to gerrit, which
is very easy to set up:

https://wiki.documentfoundation.org/Development/gerrit

also, please send a license mail as described on:

https://wiki.documentfoundation.org/Development/Developers#Example_Statement

> > $ pkgdiff Executable_pluginapp.bin.mk
> > $NetBSD$
> >
> > --- Executable_pluginapp.bin.mk.orig 2014-04-30 19:49:45.000000000 +0000
> > +++ Executable_pluginapp.bin.mk
> > @@ -33,15 +33,7 @@ $(eval $(call gb_Executable_use_librarie
> >      sal \
> >  ))
> >
> > -ifeq ($(OS),SOLARIS)
> > -$(eval $(call gb_Executable_add_libs,pluginapp.bin,\
> > -    -lXm \
> > -    -lXt \
> > -    -lXext \
> > -    -lX11 \
> > -    -ldl \
> > -))
> > -else ifeq ($(filter-out FREEBSD NETBSD OPENBSD DRAGONFLY,$(OS)),)
> > +ifeq ($(filter-out FREEBSD NETBSD OPENBSD DRAGONFLY,$(OS)),)
> >  $(eval $(call gb_Executable_add_libs,pluginapp.bin,\
> >      -lXt \
> >      -lXext \
> > @@ -73,7 +65,7 @@ $(eval $(call gb_Executable_use_external
> >  ))
> >
> >  # the orignal dmakefile said: don't ask, it's ugly

^^^ this is really a particularly unhelpful comment :-/

> > -ifeq ($(OS),SOLARIS)
> > +ifeq ($(OS),XSOLARIS)
> >  $(eval $(call gb_Executable_set_ldflags,pluginapp.bin,\
> >      -z nodefs \
> >  ))
>
> BTW, for the moment, I don't have an issue with omitting the -znodefs
> perhaps an old problem since resolved... will keep an eye out.

and indeed looking at the git log there is no hint as to what problem is
actually being solved here, so i'd say it's best to remove this block
completely if that works for you.

regards
 michael