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]> 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-07 16:35 Chapman Flack <[email protected]> parent: 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-09 23:50 Chapman Flack <[email protected]> parent: 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