> In the end, we link all static libs + object files in a single
executable.
I see. I had missed that you said "libjavafx_iio.a", meaning static
linking. No, I don't know how to make that work, either. Name mangling
might be the best solution then.
-- Kevin
Johan Vos wrote:
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 <mailto: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
>
