FLTK logo

Re: [fltk/fltk] [fltk 1.4.x/Linux] application invoking native chooser crashes under linux if if fltk built with --enable-localpng (#232)

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.issues  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: [fltk/fltk] [fltk 1.4.x/Linux] application invoking native chooser crashes under linux if if fltk built with --enable-localpng (#232) erco77 May 25, 2021  
 

Yikes, I was afraid there might be some old C style code in PNG/JPEG/etc. I don't think C++ allows k&r style parameters /at all/.

Doing some research, there's tools like objcopy --prefix-symbols that can insert a prefix into all global symbols of an already built static lib, so if e.g. our png library is built static, that can be invoked after to rename the symbols. But that surely doesn't apply to all platforms/compilers..

I'm afraid that's all I've got offhand, as I'm in the middle of coding in production again, and can't split my time at the moment.
I just did a quick google search for "resolving global symbol conflicts in libraries" and found these:
https://www.ivolve.com/solving-c-symbol-collisions/
https://stackoverflow.com/questions/6940384/how-to-deal-with-symbol-collisions-between-statically-linked-libraries

Sounds like objcopy --prefix-symbols fl_ somepng.o is something one can do to insert prefixes on all global symbols for a statically built lib, but I'm not sure that carries to all compilers/platforms we support.

Not surprisingly, seems other tools have been down this path, e.g. DynamoRIO/dynamorio#3348
Quoting the OP of that issue:

We're using DR as a static library more and more these days, and the current solution for
hiding its global symbols, running objcopy --localize-hidden, is a fragile post-link step that
conflicts with other build steps such as lld's ICF and which can break when used in complex
 build configurations.

On a whim, looking at the png library, it /seems/ like they /may/ provide some mechanisms for symbol name prefixing. I just grepped the .h files for 'prefix' and found a few hits. Might be worth researching, not sure if any of it is relevant or not. This one comment caught my eye:

/* To support symbol prefixing it is necessary to know *before* including png.h
 * whether the fixed point (and maybe other) APIs are exported, because if they
 * are not internal definitions may be required.  This is handled below just
 * before png.h is included, but load the configuration now if it is available.
 */

There was also something called PNG_PREFIX in png.h, but again didn't read into it.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.