public inbox for [email protected]
help / color / mirror / Atom feed[Pljava-dev] Mac OS X expertise needed
3+ messages / 1 participants
[nested] [flat]
* [Pljava-dev] Mac OS X expertise needed
@ 2015-11-06 15:22 Chapman Flack <[email protected]>
2015-11-07 16:35 ` Re: [Pljava-dev] Mac OS X expertise needed Chapman Flack <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Chapman Flack @ 2015-11-06 15:22 UTC (permalink / raw)
Hi,
Daniel at Hopla Software has opened a PL/Java issue about
building with Maven on OS X 10.11.1 :
https://github.com/tada/pljava/issues/63
From the details he has posted, I am sure it must be something
simple about the options being passed to the OS X build toolchain -
the linker is complaining about what looks like every single symbol
being unresolved *including those defined in the PL/Java code
itself*!
But I have no experience with quirks of the OS X toolchain, and
I have no El Capitan machine to experiment with.
It looks like the PostgreSQL 9.4.4 instance he is building against
is a dual-architecture build (pg_config reports "-arch i386 -arch
x86_64"), which may or may not be a factor. The g++ linker errors
say specifically "Undefined symbols for architecture x86_64:".
(Before you think "oh, that's easy then": the gcc compiler command
being generated does say "-arch x86_64".)
Does this issue ring any bells for anyone?
Thanks,
-Chap
_______________________________________________
Pljava-dev mailing list
[email protected]
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [Pljava-dev] Mac OS X expertise needed
2015-11-06 15:22 [Pljava-dev] Mac OS X expertise needed Chapman Flack <[email protected]>
@ 2015-11-07 16:35 ` Chapman Flack <[email protected]>
2015-11-09 23:50 ` [Pljava-dev] [solved] Re: Mac OS X expertise needed Chapman Flack <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Chapman Flack @ 2015-11-07 16:35 UTC (permalink / raw)
I wrote:
> https://github.com/tada/pljava/issues/63
>
> ... I am sure it must be something
> simple about the options being passed to the OS X build toolchain -
> the linker is complaining about what looks like every single symbol
> being unresolved *including those defined in the PL/Java code
> itself*!
I was mistaken about that last part, not reading the verbose linker
messages correctly. The only undefined symbols it was complaining about
were, well, everything defined in PostgreSQL.
When I build on linux, the linker just happily creates a .so file with
all those symbols listed as undefined, and they get hooked up to the
real things in PostgreSQL at the time the backend loads the library.
So what would be making the OS X linker think it has to resolve them all
at link time? Is there an extra option it needs telling it "relax, leave
things undefined, you're building a dylib"? It is already being passed
the -dynamiclib option. Do all the extern symbols need some special extra
annotation in OS X?
-Chap
_______________________________________________
Pljava-dev mailing list
[email protected]
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
^ permalink raw reply [nested|flat] 3+ messages in thread
* [Pljava-dev] [solved] Re: Mac OS X expertise needed
2015-11-06 15:22 [Pljava-dev] Mac OS X expertise needed Chapman Flack <[email protected]>
2015-11-07 16:35 ` Re: [Pljava-dev] Mac OS X expertise needed Chapman Flack <[email protected]>
@ 2015-11-09 23:50 ` Chapman Flack <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Chapman Flack @ 2015-11-09 23:50 UTC (permalink / raw)
> So what would be making the OS X linker think it has to resolve them all
> at link time? Is there an extra option it needs telling it "relax, leave
> things undefined, you're building a dylib"? It is already being passed
> the -dynamiclib option. Do all the extern symbols need some special extra
> annotation in OS X?
It turns out in OS X there is a distinction between a .dylib and a .bundle
(the nar-maven-plugin calls them 'shared' and 'plugin' respectively, which
are equivalent on other platforms, but different on OS X).
Only a .bundle (plugin) is supposed to have unresolved refs back into the
thing that's going to load it. A .dylib should only have refs into its
link-time dependencies.
The PL/Java pom said 'shared', which was no problem on non-OS X platforms,
but should really be 'plugin'.
When the change is merged, it will have the side effect of changing the
path where the built file is found under pljava-so/target (the word
shared becomes plugin, both places), meaning a change to Bear's build
instructions on the wiki.
PGXS also knows how to build 'plugin's, and it coerces the file extension
back to the Unixy .so instead of the OS X .bundle. Maven gives them the
.bundle extension conforming to OS X practice. That could just be covered
in docs for Mac installation, or the build could be made to rename the file
to .so.
-Chap
_______________________________________________
Pljava-dev mailing list
[email protected]
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2015-11-09 23:50 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2015-11-06 15:22 [Pljava-dev] Mac OS X expertise needed Chapman Flack <[email protected]>
2015-11-07 16:35 ` Chapman Flack <[email protected]>
2015-11-09 23:50 ` Chapman Flack <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox