Yes, making everything except for av_ hidden by default would be more
consistent with the current build process, which includes libavcodec.v.
Though, this is a special case that results not only in increasing the
shared object file size if libavcodec.v is not used, which is
undesirable, yet harmless, but also in making the library not linkable
with PIC at all unless those symbols are hidden or forced to be resolved
at link time some other way.
Thanks for implementing the fix very quickly, by the way!
I'd also suggest writing a comment in the code describing specifically
the original issue that the current instances of the usage of
visibility("hidden") resolves, so the reason why it's used there is not
forgotten, and there's a clear pattern of relation between movrel X()
and av_visibility_hidden to follow when adding new assembly code. Though
if the convention is to rely on `git blame` for this purpose, that
shouldn't be necessary.
— Triang3l
On 11/07/2022 15:12, Henrik Gramner wrote:
On Mon, Jul 11, 2022 at 11:19 AM Martin Storsjö <mar...@martin.st> wrote:
+#if (AV_GCC_VERSION_AT_LEAST(4,0) || defined(__clang__)) && (defined(__ELF__)
|| defined(__MACH__))
+# define av_visibility_hidden __attribute__((visibility("hidden")))
+#else
+# define av_visibility_hidden
+#endif
The usual approach is to compile with -fvisibility=hidden and
explicitly flag exported API symbols.
Is there a reason for doing this the other way around?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
