Ok so in main/RepositoryFixes.mk I did try to replicate what dmake was
doing, building a .so instead of a .dylib:

# pyuno.so even on Mac OS X, because it is a python module
gb_Library_FILENAMES := $(patsubst
pyuno_loader:libpyuno%,pyuno_loader:pyuno.so,$(gb_Library_FILENAMES))

but then it apparently made a symlink to itself...

We symlink in solenv/gbuild/platform/macosx.mk:
        $(if $(filter Library,$(TARGETTYPE)),\
                $(PERL) $(SOLARENV)/bin/macosx-change-install-names.pl
Library $(LAYER) $(1) && \
                ln -shf $(1) $(patsubst %.dylib,%.jnilib,$(1)) &&) \

I think that's the problem. In that bottom line, $(1) is /path/pyuno.so,
but because it's ending in .so, the patsubst won't do a replacement, so
ends up running:
ln -shf $(1) $(1)

Maybe we should skip symlinking when it's not a .dylib?

Please try the attached patch.

On Tue, Feb 12, 2019 at 10:03 PM Jim Jagielski <j...@jagunet.com> wrote:

> <aoo-builder64-macos13:asf/trunk/main> % ls -l solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/*py*
> -rwxr-xr-x <http://unxmaccx.pro/workdir/LinkTarget/Library/*py*-rwxr-xr-x>
> 1 jim  staff  205276 Feb 12 13:27 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.dylib*
> lrwxr-xr-x
> <http://unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.dylib*lrwxr-xr-x>
> 1 jim  staff      95 Feb 12 13:27 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.jnilib@ ->
> /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.dylib
> -rwxr-xr-x
> <http://unxmaccx.pro/workdir/LinkTarget/Library/libpyuno.dylib-rwxr-xr-x>
> 1 jim  staff   25100 Feb 12 14:35 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.dylib*
> lrwxr-xr-x
> <http://unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.dylib*lrwxr-xr-x>
> 1 jim  staff     103 Feb 12 14:35 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.jnilib@ ->
> /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.dylib
> lrwxr-xr-x
> <http://unxmaccx.pro/workdir/LinkTarget/Library/pythonloader.uno.dyliblrwxr-xr-x>
> 1 jim  staff      89 Feb 12 14:35 solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so@ ->
> /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so
>
>
> > On Feb 12, 2019, at 1:16 PM, Damjan Jovanovic <dam...@apache.org> wrote:
> >
> > Please run:
> > ls -l /Users/jim/src/asf/trunk/main/solver/450/
> > unxmaccx.pro/workdir/LinkTarget/Library/*py*
> >
> > On Tue, Feb 12, 2019 at 8:08 PM Jim Jagielski <j...@jagunet.com> wrote:
> >
> >> Different issue but also affects macOS:
> >>
> >> [ build DEP ] LNK:Library/libpyuno.dylib
> >> [ build LNK ] Library/libpyuno.dylib
> >> [ build CMP ] pyuno/source/loader/pythonloader
> >> [ build CMP ] pyuno/source/loader/pythonloader
> >> [ build LNK ] Library/pyuno.so
> >> [ build CHK ] pyuno
> >> [ build CHK ] loaded modules: pyuno
> >> [ build PKG ] pyuno_py
> >> [ build PKG ] pyuno_pyuno_ini
> >> make: stat: /Users/jim/src/asf/trunk/main/solver/450/
> >> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so: Too many levels of
> >> symbolic links
> >> touch: /Users/jim/src/asf/trunk/main/solver/450/
> >> unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so: Too many levels of
> >> symbolic links
> >> make: *** [/Users/jim/src/asf/trunk/main/solenv/gbuild/Package.mk:28:
> >> /Users/jim/src/asf/trunk/main/solver/450/unxmaccx.pro/lib/pyuno.so]
> Error
> >> 1
> >> make: *** Waiting for unfinished jobs....
> >> dmake:  Error code 2, while making 'all'
> >>
> >> 1 module(s):
> >>        pyuno
> >> need(s) to be rebuilt
> >>
> >>
> >>> On Feb 12, 2019, at 10:02 AM, Matthias Seidel <
> >> matthias.sei...@hamburg.de> wrote:
> >>>
> >>> Linux64 and Linux32 also break, but in in pyuno: <>
> >>>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/linux64/main/pyuno/unxlngx6.pro/misc/logs/prj.txt
> >> <>
> >>>
> >>
> https://ci.apache.org/projects/openoffice/buildlogs/linux32/main/pyuno/unxlngi6.pro/misc/logs/prj.txt
> >> <>
> >>> Maybe it is related?
> >>> <>
> >>> Regards, <>
> >>>   Matthias
> >>> <>
> >>> Am 11.02.19 um 20:56 schrieb Damjan Jovanovic:
> >>>> On Mon, Feb 11, 2019 at 8:03 PM Jim Jagielski <j...@jagunet.com>
> >> <mailto:j...@jagunet.com> wrote:
> >>>>
> >>>>> Uggg....
> >>>>>
> >>>>> looks like breakage from the solenv port to gbuild???
> >>>>>
> >>>>>
> >>>> Are you sure?
> >>>>
> >>>> I don't see how, it's a very simple port.
> >>>>
> >>
> >>
>
>
diff --git a/main/solenv/gbuild/platform/macosx.mk b/main/solenv/gbuild/platform/macosx.mk
index 1836061749..1e814fd8ea 100644
--- a/main/solenv/gbuild/platform/macosx.mk
+++ b/main/solenv/gbuild/platform/macosx.mk
@@ -319,7 +319,7 @@ $(call gb_Helper_abbreviate_dirs,\
 		`cat $${DYLIB_FILE}` && \
 	$(if $(filter Library,$(TARGETTYPE)),\
 		$(PERL) $(SOLARENV)/bin/macosx-change-install-names.pl Library $(LAYER) $(1) && \
-		ln -shf $(1) $(patsubst %.dylib,%.jnilib,$(1)) &&) \
+		$(if $(filter %.dylib,$(1)),ln -shf $(1) $(patsubst %.dylib,%.jnilib,$(1)) &&)) \
 	rm -f $${DYLIB_FILE})
 endef
 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to