At the risk of being stupid, but I don't see how I could make the JPEG symbols invisible, as they are still needed by the native functions in javafx_iio (in jpegloader.c). If they are invisible, jpegloader.o won't be able to access them either, no? In the end, we link all static libs + object files in a single executable. If they were in the same file as jpegloader, I would make them static so they wouldn't be exported, but I don't know how I can make those symbols available to jpegloader.c without exporting them?
- Johan On Wed, Jan 24, 2018 at 6:24 PM Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > Hiding the symbols seems like a better solution than shipping two > binaries, and is probably easier than mangling the symbols. > > -- Kevin > > > Phil Race wrote: > > Does libjavafx_iio.a really need to export the JPEG symbols ? > > On Windows, or Linux, or Solaris .. there are ways > > to limit the exported symbols from a library. > > > > I found this page for macos : > > > > > https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/ExportingInterfaces.html > > > > > > Not a complete answer but maybe somewhere to start. > > > > -phil. > > > > On 01/24/2018 02:42 AM, Johan Vos wrote: > >> Hi, > >> > >> We are currently building a native library for javafx_iio which includes > >> libjpeg7. As a consequence, those symbols are included in the static > >> libjavafx_iio.a on iOS. If we add other libraries (e.g. OpenCV) this can > >> result in duplicate symbols, as the libjpeg7 library might be > >> included in > >> other frameworks as well. > >> > >> As a dirty hack, I build 2 versions of libjavafx_iio.a: one with > >> libjpeg7, > >> and one without. A better solution might be to prefix the symbols in the > >> libjpeg7 files. > >> > >> Or are there better ideas? > >> > >> Thanks, > >> > >> - Johan > > >
