lipjpeg7 in static library

[Johan Vos]

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.rushforth at 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
> >
>