openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: svn commit: r1853643 - in /openoffice/trunk/main: ./ apple_remote/ apple_remote/prj/ apple_remote/source/
Date Wed, 20 Feb 2019 17:14:23 GMT
I wonder if the problem is that gbuild's default symbol visibility is
hidden, unlike dmake's which was public.

Can you post the output of:
nm -D solver/450/<macprefix>/lib/*AppleRemote.dylib | grep ' T '
and compare against the same from any version before the gbuild commit?

In C/C++ we have to mark functions to export with SAL_DLLPUBLIC_EXPORT in
the .c/.cxx files, or use a more complex setup with a dllapi.h file (
https://wiki.openoffice.org/wiki/Symbol_Visibility) when the functions are
declared in header files. Objective C probably needs something similar.

On Wed, Feb 20, 2019 at 7:05 PM Jim Jagielski <jim@jagunet.com> wrote:

> The patch is applied (as well as some other changes) and apple_remote
> builds, but it looks like even though it builds, some linking issues are
> still there:
>
> [ build RES ] vclen-GB
> Undefined symbols for architecture x86_64:
>   "_OBJC_CLASS_$_AppleRemoteMainController", referenced from:
>       objc-class-ref in salinst.o
>   "_OBJC_IVAR_$_AppleRemoteMainController.remoteControl", referenced from:
>       -[VCL_NSApplication applicationWillBecomeActive:] in vclnsapp.o
>       -[VCL_NSApplication applicationWillResignActive:] in vclnsapp.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make: *** [/Users/jim/src/asf/trunk/main/solenv/gbuild/LinkTarget.mk:330:
> /Users/jim/src/asf/trunk/main/solver/450/
> unxmaccx.pro/workdir/LinkTarget/Library/libvcl.dylib] Error 1
> make: *** Waiting for unfinished jobs....
> dmake:  Error code 2, while making 'all'
>
>
>
> > On Feb 19, 2019, at 8:59 PM, Damjan Jovanovic <damjan@apache.org> wrote:
> >
> > Yes, changes to gbuild itself are largely made by experimentation. It's
> beyond anyone's complete understanding.
> >
> > Please try this patch, with the file extensions back on *.m.
> >
> > On Tue, Feb 19, 2019 at 10:39 PM Jim Jagielski <jim@jagunet.com <mailto:
> jim@jagunet.com>> wrote:
> >
> >
> > > On Feb 19, 2019, at 12:05 PM, Damjan Jovanovic <damjan@apache.org
> <mailto:damjan@apache.org>> wrote:
> > >
> > >  If
> > > not, I'll have to make a gb_Library_add_objcobjects API instead.
> >
> > If I knew how, I'd do it. Looking over the add_objcxxobjects stuff it
> seems like a maze of twisty little passages
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org <mailto:
> dev-unsubscribe@openoffice.apache.org>
> > For additional commands, e-mail: dev-help@openoffice.apache.org <mailto:
> dev-help@openoffice.apache.org>
> >
> > <macosx-objective-c.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