Static library symbols shall be marked as hidden

[GoogleCodeExporter]

Hi,

I think that when compiling static library, symbols shall always be marked as 
"hidden" (opposed to "default") so that they won't be exported from the shared 
object they're linked into.

Regards,
Matthieu

Original issue reported on code.google.com by m.darb...@gmail.com on 5 Jun 2014 at 7:20

Attachments:

• openjpeg-2.1.0-visibility.patch

[GoogleCodeExporter]

@Mathieu,

Any thoughts on this one so that I can fix/won't fix it ?

Original comment by m.darb...@gmail.com on 3 Dec 2014 at 8:25

[GoogleCodeExporter]

define "compiling static library" [...] "shared object" ?

Original comment by mathieu.malaterre on 4 Dec 2014 at 7:52

[GoogleCodeExporter]

If you compile OpenJPEG with -DOPJ_STATIC (that is CMAKE option 
BUILD_SHARED_LIBS=FALSE) on linux, OPJ_API gets defined like this:
#define OPJ_API    __attribute__ ((visibility ("default")))

Now, if I create a libfoo.so that has been linked against the OpenJPEG static 
library, symbols from the OpenJPEG API will be exported which can lead to odd 
behaviour if an executable links against libfoo.so & libopenjp2.so because the 
executable expects symbols from libopenjp2.so but might resolve those from 
libfoo.so instead (depending on loading order & OpenJPEG version conflict)

I said "shared objects" because this is also true of executables but with some 
specific options so not that relevant & confusing I guess.

Original comment by m.darb...@gmail.com on 4 Dec 2014 at 9:04

[GoogleCodeExporter]

This seems quite right.
@Mathieu Malaterre: do you have any objection to this? Thks

Original comment by antonin on 15 Jan 2015 at 6:25

• Changed state: Started

[GoogleCodeExporter]

Sorry to insist but:
[...]
Now, if I create a libfoo.so that has been linked against the OpenJPEG static 
library, symbols from the OpenJPEG API will be exported 
[...]

does not make any sense to me. I think I am missing the whole point. Why would 
a symbol from libfoo project (re)export something from libopenjp2.a ?

Original comment by mathieu.malaterre on 15 Jan 2015 at 7:51

[GoogleCodeExporter]

@mathieu,

This is just how the linker works under linux/macos. Here's a small example 
attached (you'll have to modify it a little in order for it to work under 
linux).

Here's the output under MacOS. Have a look at all 4 outputs from the test "A : 
x - B : y". One would expect the output to always be "A : 0 - B : 1" but this 
is not the case
 # As OpenJpeg is now (a is representing OpenJPEG)
+ gcc -fPIC -x c -O3 -c -DA_VISIBILITY_DEFAULT -DA_VERSION=0 -o a0.o a.c
+ gcc -fPIC -x c -O3 -c -DA_VISIBILITY_DEFAULT -DA_VERSION=1 -o a1.o a.c
+ gcc -fPIC -x c -O3 -c -o b.o b.c
+ gcc -fPIC -shared -o liba.dylib a0.o
+ ar rc liba.a a1.o
+ gcc -fPIC -shared -o libb.dylib b.o liba.a
+ gcc -fPIE -x c -O3 -DA_VISIBILITY_DEFAULT -o ab -Wl,liba.dylib -Wl,libb.dylib 
main.c
+ gcc -fPIE -x c -O3 -DA_VISIBILITY_DEFAULT -o ba -Wl,libb.dylib -Wl,liba.dylib 
main.c
+ ./ab
A : 0 - B : 1
+ ./ba
A : 1 - B : 1
# As OpenJpeg should be
+ gcc -fPIC -x c -O3 -c -DA_VISIBILITY_DEFAULT -DA_VERSION=0 -o a0.o a.c
+ gcc -fPIC -x c -O3 -c -DA_VERSION=1 -o a1.o a.c
+ gcc -fPIC -x c -O3 -c -o b.o b.c
+ gcc -fPIC -shared -o liba.dylib a0.o
+ ar rc liba.a a1.o
+ gcc -fPIC -shared -o libb.dylib b.o liba.a
+ gcc -fPIE -x c -O3 -DA_VISIBILITY_DEFAULT -o ab -Wl,liba.dylib -Wl,libb.dylib 
main.c
+ gcc -fPIE -x c -O3 -DA_VISIBILITY_DEFAULT -o ba -Wl,libb.dylib -Wl,liba.dylib 
main.c
+ ./ab
A : 0 - B : 1
+ ./ba
A : 0 - B : 1

Original comment by m.darb...@gmail.com on 15 Jan 2015 at 10:19

Attachments:

• test.tar.gz

[GoogleCodeExporter]

$ LD_LIBRARY_PATH=`pwd` ./test.sh 
+ gcc -fPIC -x c -O3 -c -DA_VISIBILITY_DEFAULT -DA_VERSION=0 -o a0.o a.c
+ gcc -fPIC -x c -O3 -c -DA_VISIBILITY_DEFAULT -DA_VERSION=1 -o a1.o a.c
+ gcc -fPIC -x c -O3 -c -o b.o b.c
+ gcc -fPIC -shared -o liba.dylib a0.o
+ ar rc liba.a a1.o
+ gcc -fPIC -shared -o libb.dylib b.o liba.a
+ gcc -fPIE -x c -O3 -DA_VISIBILITY_DEFAULT -o ab -Wl,liba.dylib -Wl,libb.dylib 
main.c
+ gcc -fPIE -x c -O3 -DA_VISIBILITY_DEFAULT -o ba -Wl,libb.dylib -Wl,liba.dylib 
main.c
+ ./ab
A : 0 - B : 1
+ ./ba
A : 0 - B : 1
+ gcc -fPIC -x c -O3 -c -DA_VISIBILITY_DEFAULT -DA_VERSION=0 -o a0.o a.c
+ gcc -fPIC -x c -O3 -c -DA_VERSION=1 -o a1.o a.c
+ gcc -fPIC -x c -O3 -c -o b.o b.c
+ gcc -fPIC -shared -o liba.dylib a0.o
+ ar rc liba.a a1.o
+ gcc -fPIC -shared -o libb.dylib b.o liba.a
+ gcc -fPIE -x c -O3 -DA_VISIBILITY_DEFAULT -o ab -Wl,liba.dylib -Wl,libb.dylib 
main.c
+ gcc -fPIE -x c -O3 -DA_VISIBILITY_DEFAULT -o ba -Wl,libb.dylib -Wl,liba.dylib 
main.c
+ ./ab
A : 0 - B : 1
+ ./ba
A : 0 - B : 1

With:

$ gcc --version
gcc (Debian 4.9.1-19) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Original comment by mathieu.malaterre on 16 Jan 2015 at 8:07

[GoogleCodeExporter]

The scenario you describe is in comment #3:

[...]
which can lead to odd behaviour if an executable links against libfoo.so & 
libopenjp2.so
[...]

Are you sure the standard define a behavior for this use case ? Isn't it 
implementation defined ? Anyway if this is UB, then feel free to apply the 
patch, since it seems to do the right thing on clang/MacOSX (as seen on your 
console output).

Original comment by mathieu.malaterre on 16 Jan 2015 at 8:15

[GoogleCodeExporter]

http://stackoverflow.com/a/9094015/136285

Original comment by mathieu.malaterre on 16 Jan 2015 at 10:50

[GoogleCodeExporter]

I got my hand on multiple linux distribs today.
There are quite a lot of different behaviour for the first part... (including 
the same as MacOs, The same as yours and others...).
On ubuntu 12.04, if you compile b object with -DA_VISIBILITY_DEFAULT in the 
first part (the line that was commented out but shouldn't have been as it's 
more accurate in representing OpenJPEG than the other line - guess I was wrong 
about visibility only applying when building symbols), I get :
+ ./ab
A : 0 - B : 0
+ ./ba
A : 1 - B : 1
I wouldn't have thought so...

The only trick that seems to work on all distribs is the proposed one.
I'll get a patch for this.

Original comment by m.darb...@gmail.com on 19 Jan 2015 at 11:34

[GoogleCodeExporter]

This issue was closed by revision r2994.

Original comment by m.darb...@gmail.com on 25 Jan 2015 at 4:59

• Changed state: Fixed