openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: macOS on trunk broken again
Date Wed, 13 Feb 2019 12:26:22 GMT
On inspection the patch seems quite logical... testing as we speak.

Thx.

> On Feb 12, 2019, at 8:34 PM, Damjan Jovanovic <damjan@apache.org> wrote:
> 
> 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 <http://macosx.mk/>:
>         $(if $(filter Library,$(TARGETTYPE)),\
>                 $(PERL) $(SOLARENV)/bin/macosx-change-install-names.pl <http://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 <jim@jagunet.com <mailto:jim@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@
<http://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@
<http://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@
<http://unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so@> -> /Users/jim/src/asf/trunk/main/solver/450/unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so
<http://unxmaccx.pro/workdir/LinkTarget/Library/pyuno.so>
> 
> 
> > On Feb 12, 2019, at 1:16 PM, Damjan Jovanovic <damjan@apache.org <mailto:damjan@apache.org>>
wrote:
> > 
> > Please run:
> > ls -l /Users/jim/src/asf/trunk/main/solver/450/
> > unxmaccx.pro/workdir/LinkTarget/Library/*py* <http://unxmaccx.pro/workdir/LinkTarget/Library/*py*>
> > 
> > On Tue, Feb 12, 2019 at 8:08 PM Jim Jagielski <jim@jagunet.com <mailto:jim@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 <http://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 <http://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 <http://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.seidel@hamburg.de <mailto:matthias.seidel@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/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
<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 <jim@jagunet.com <mailto:jim@jagunet.com>>
> >> <mailto:jim@jagunet.com <mailto:jim@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.
> >>>> 
> >> 
> >> 
> 
> <mac-linking.patch>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message