Re: suggestion for adding sdk/lib to pluginapp.bin or libuno_sal.so symlink in ure/lib
Le 21/05/14 10:56, Stephan Bergmann a écrit : On 05/21/2014 07:13 AM, Richard PALO wrote: S=/var/tmp/pkgsrc/misc/libreoffice4/work/libreoffice-4.2.4.2 I=$S/instdir W=$S/workdir g++-Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -L$I/ure/lib -L$I/program -z nodefs $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o -Wl,--start-group $W/LinkTarget/StaticLibrary/libplugcon.a -lm -lnsl -lsocket -lXt -lXext -lX11 -ldl -L/opt/local/lib -Wl,-R/opt/local/lib -lgthread-2.0 -lpthread -lthread -Wl,-R/opt/local/lib -lglib-2.0 -lintl -L/opt/local/lib -Wl,-R/opt/local/lib -lgtk-x11-2.0 -Wl,-R/opt/local/lib -lgdk-x11-2.0 -Wl,-R/opt/local/lib -lpangocairo-1.0 -Wl,-R/opt/local/lib -latk-1.0 -Wl,-R/opt/local/lib -lcairo -Wl,-R/opt/local/lib -lgio-2.0 -Wl,-R/opt/local/lib -lpangoft2-1.0 -Wl,-R/opt/local/lib -lpango-1.0 -Wl,-R/opt/local/lib -lfontconfig -Wl,-R/opt/local/lib -lfreetype -Wl,-R/opt/local/lib -lgdk_pixbuf_xlib-2.0 -Wl,-R/opt/local/lib -lgmodule-2.0 -lpthread -lthread -Wl,-R/opt/local/lib -lgdk_pixbuf-2.0 -Wl,-R/opt/local/lib -lgobject-2.0 -Wl,-R/opt/local/lib -lglib-2.0 -lintl -L/opt/local/lib -Wl,-R/opt/local/lib -lgtk-x11-2.0 -Wl,-R/opt/local/lib -lgdk-x11-2.0 -Wl,-R/opt/local/lib -lpangocairo-1.0 -Wl,-R/opt/local/lib -latk-1.0 -Wl,-R/opt/local/lib -lcairo -Wl,-R/opt/local/lib -lgdk_pixbuf-2.0 -Wl,-R/opt/local/lib -lgio-2.0 -Wl,-R/opt/local/lib -lpangoft2-1.0 -Wl,-R/opt/local/lib -lpango-1.0 -Wl,-R/opt/local/lib -lgobject-2.0 -Wl,-R/opt/local/lib -lglib-2.0 -lintl -Wl,-R/opt/local/lib -lfontconfig -Wl,-R/opt/local/lib -lfreetype -Wl,--end-group -Wl,--no-as-needed -luno_sal -o $I/program/pluginapp.bin ld: fatal: library -luno_sal: not found = 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: # call gb_LinkTarget_add_ldflags,linktarget,ldflags define gb_LinkTarget_add_ldflags $(call gb_LinkTarget_get_target,$(1)) : T_LDFLAGS += $(2) endef # real use in RepositoryExternal.mk # call gb_LinkTarget_set_ldflags,linktarget,ldflags define gb_LinkTarget_set_ldflags $(call gb_LinkTarget_get_target,$(1)) : T_LDFLAGS := $(2) ^^ Earlier in LinkTarget.mk your function is evaluted thus: $(call gb_LinkTarget_get_target,$(1)) : T_LDFLAGS := $$(gb_LinkTarget_LDFLAGS) $(call gb_LinkTarget_get_linksearchpath_for_layer,$(3)) $(call gb_LinkTarget__get_ldflags,$(2)) therefore overridden by the subsequent set_ldflags call. In summary, the following patch to Executable_pluginapp.bin.mk seems to build for now (the first part is because motif is, well...:-): $ pkgdiff Executable_pluginapp.bin.mk $NetBSD$ --- Executable_pluginapp.bin.mk.orig2014-04-30 19:49:45.0 + +++ 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 -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. cheers ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: suggestion for adding sdk/lib to pluginapp.bin or libuno_sal.so symlink in ure/lib
On 05/23/2014 08:59 AM, Richard PALO wrote: @@ -73,7 +65,7 @@ $(eval $(call gb_Executable_use_external )) # the orignal dmakefile said: don't ask, it's ugly -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. Ah, so either indeed drop it completely (which is probably best overall) or turn it into a gb_Executable_add_ldflags call. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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.0 + +++ 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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: suggestion for adding sdk/lib to pluginapp.bin or libuno_sal.so symlink in ure/lib
On 05/21/2014 07:13 AM, Richard PALO wrote: S=/var/tmp/pkgsrc/misc/libreoffice4/work/libreoffice-4.2.4.2 I=$S/instdir W=$S/workdir g++-Wl,-z,origin '-Wl,-rpath,$ORIGIN:$ORIGIN/../ure-link/lib' -L$I/ure/lib -L$I/program -z nodefs $W/CxxObject/extensions/source/plugin/unx/npwrap.o $W/CxxObject/extensions/source/plugin/unx/npnapi.o -Wl,--start-group $W/LinkTarget/StaticLibrary/libplugcon.a -lm -lnsl -lsocket -lXt -lXext -lX11 -ldl -L/opt/local/lib -Wl,-R/opt/local/lib -lgthread-2.0 -lpthread -lthread -Wl,-R/opt/local/lib -lglib-2.0 -lintl -L/opt/local/lib -Wl,-R/opt/local/lib -lgtk-x11-2.0 -Wl,-R/opt/local/lib -lgdk-x11-2.0 -Wl,-R/opt/local/lib -lpangocairo-1.0 -Wl,-R/opt/local/lib -latk-1.0 -Wl,-R/opt/local/lib -lcairo -Wl,-R/opt/local/lib -lgio-2.0 -Wl,-R/opt/local/lib -lpangoft2-1.0 -Wl,-R/opt/local/lib -lpango-1.0 -Wl,-R/opt/local/lib -lfontconfig -Wl,-R/opt/local/lib -lfreetype -Wl,-R/opt/local/lib -lgdk_pixbuf_xlib-2.0 -Wl,-R/opt/local/lib -lgmodule-2.0 -lpthread -lthread -Wl,-R/opt/local/lib -lgdk_pixbuf-2.0 -Wl,-R/opt/local/lib -lgobject-2.0 -Wl,-R/opt/local/lib -lglib-2.0 -lintl -L/opt/local/lib -Wl,-R/opt/local/lib -lgtk-x11-2.0 -Wl,-R/opt/local/lib -lgdk-x11-2.0 -Wl,-R/opt/local/lib -lpangocairo-1.0 -Wl,-R/opt/local/lib -latk-1.0 -Wl,-R/opt/local/lib -lcairo -Wl,-R/opt/local/lib -lgdk_pixbuf-2.0 -Wl,-R/opt/local/lib -lgio-2.0 -Wl,-R/opt/local/lib -lpangoft2-1.0 -Wl,-R/opt/local/lib -lpango-1.0 -Wl,-R/opt/local/lib -lgobject-2.0 -Wl,-R/opt/local/lib -lglib-2.0 -lintl -Wl,-R/opt/local/lib -lfontconfig -Wl,-R/opt/local/lib -lfreetype -Wl,--end-group -Wl,--no-as-needed -luno_sal -o $I/program/pluginapp.bin ld: fatal: library -luno_sal: not found = 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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
