I have the question concerning the following dh_shlibdeps warning, which
is triggered for library that is compiled witn OpenMP support:
> dh_shlibdeps
> dpkg-shlibdeps: warning: symbol GOMP_critical_start used by debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries.
> dpkg-shlibdeps: warning: symbol GOMP_parallel_start used by debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries.
> dpkg-shlibdeps: warning: symbol omp_get_num_threads used by debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries.
> dpkg-shlibdeps: warning: symbol GOMP_critical_end used by debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries.
> dpkg-shlibdeps: warning: symbol omp_get_thread_num used by debian/libosra0/usr/lib/libosra.so.0.0.10308 found in none of the libraries.
The mentioned symbols are exported from libgomp (a part of gcc-4.4
package), which is correctly linked to the SO:
What should I do to suppress this warning? Or should it be silently ignored?
Thanks in advance.
--
With best regards,
Dmitry
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D94A68E.7060906@mail.ru">http://lists.debian.org/4D94A68E.7060906@mail.ru
Dmitry Katsubo <dma_k@mail.ru> (31/03/2011):
> The mentioned symbols are exported from libgomp (a part of gcc-4.4
> package), which is correctly linked to the SO:
>
> # ldd ./src/libosra_java.so | grep gomp
> libgomp.so.1 => /usr/lib/libgomp.so.1 (0xb68df000)
you may want to check through objdump -x $foo.so|grep NEEDED; ldd
shows recursive dependencies.
On 31.03.2011 18:20, Cyril Brulebois wrote:
> you may want to check through objdump -x $foo.so|grep NEEDED; ldd
> shows recursive dependencies.
>
> KiBi.
KiBi, thanks for the hint. It turned out that libgomp is not listed as
direct dependency of my library. Does it mean I have to put "gcc-4.4"
into debian/control -> Depends and add "-lgomp" to LIBS explicitly
during the linking stage?
Another problem that arises here:
I autodetect OpenMP support using AC_OPENMP() autoconf macro. So if
OpenMP is detected, then it is used, otherwise - not (optional enabled
by default dependency). How to play correctly in this situation?
libgraphicsmagick3 is also compiled with OpenMP support
(/usr/lib/libGraphicsMagick.a has omp_get_* and GOMP_* symbols
undefined), however it does not depend on "gcc-4.4".
--
With best regards,
Dmitry
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D94D795.4000801@mail.ru">http://lists.debian.org/4D94D795.4000801@mail.ru
On Thu, Mar 31, 2011 at 09:35:49PM +0200, Dmitry Katsubo wrote:
> KiBi, thanks for the hint. It turned out that libgomp is not listed as
> direct dependency of my library. Does it mean I have to put "gcc-4.4"
> into debian/control -> Depends and add "-lgomp" to LIBS explicitly
> during the linking stage?
You do need -lgomp. You should not need gcc-4.4 in Build-Depends unless
your package will not build on any other version (which is a very bad
bug), since gcc is build-essential and therefore already installed. You
certainly should not need it at runtime.
> Another problem that arises here:
>
> I autodetect OpenMP support using AC_OPENMP() autoconf macro. So if
> OpenMP is detected, then it is used, otherwise - not (optional enabled
> by default dependency). How to play correctly in this situation?
If gcc 4.3 or higher is installed it should already contain the .so
symlink that you need, so simply compile it as normal. No extra
build-dependencies are needed.
> libgraphicsmagick3 is also compiled with OpenMP support
> (/usr/lib/libGraphicsMagick.a has omp_get_* and GOMP_* symbols
> undefined), however it does not depend on "gcc-4.4".
Again, you don't need to depend on gcc. Your package will probably have
a dependency on libgomp1, but that will be automatically added if
required.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
* brian m. carlson <sandals@crustytoothpaste.net>, 2011-03-31, 20:09:
KiBi, thanks for the hint. It turned out that libgomp is not listed as
direct dependency of my library. Does it mean I have to put "gcc-4.4"
into debian/control -> Depends and add "-lgomp" to LIBS explicitly
during the linking stage?
You do need -lgomp.
You normally don't (need to) link to gomp explicitly. My wild guess is:
Dmitry used -fopenmp while compiling *.o, but not when linking the
shared library.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110331201630.GA9414@jwilk.net">http://lists.debian.org/20110331201630.GA9414@jwilk.net
On 31.03.2011 22:16, Jakub Wilk wrote:
>> You do need -lgomp.
>
> You normally don't (need to) link to gomp explicitly. My wild guess is:
> Dmitry used -fopenmp while compiling *.o, but not when linking the
> shared library.
Exactly! Thank you, Jakub, for nice guess.
AC_OPENMP() macro documentation looks to be a bit incomplete (e.g. if it
provides $OPENMP_LDFLAGS I wouldn't mess things), so I believe the
correct sequence looks like this:
I also was suggested this resource:
> http://wiki.debian.org/ToolChain/DSOLinking#Unresolved_symbols_in_shared_libraries
which explains that this warning is raised, when the dependency chain is
like "A -> B -> C", and A needs symbols from C, but has no direct
dependency "A -> C" (which should be introduced as Brian also mentioned).
Thanks a lot for help.
--
With best regards,
Dmitry
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D958B0B.1010109@mail.ru">http://lists.debian.org/4D958B0B.1010109@mail.ru
On 01/04/2011 10:21, Dmitry Katsubo wrote:
> On 31.03.2011 22:16, Jakub Wilk wrote:
>>> You do need -lgomp.
>>
>> You normally don't (need to) link to gomp explicitly. My wild guess is:
>> Dmitry used -fopenmp while compiling *.o, but not when linking the
>> shared library.
>
> Exactly! Thank you, Jakub, for nice guess.
> AC_OPENMP() macro documentation looks to be a bit incomplete (e.g. if it
> provides $OPENMP_LDFLAGS I wouldn't mess things),
Please, report a bug for this macro if it is provided by another package.
Regards,
Vincent
--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D95C750.9080908@free.fr">http://lists.debian.org/4D95C750.9080908@free.fr
* Vincent Danjean <vdanjean.ml@free.fr>, 2011-04-01, 14:38:
AC_OPENMP() macro documentation looks to be a bit incomplete (e.g. if it
provides $OPENMP_LDFLAGS I wouldn't mess things),
Please, report a bug for this macro if it is provided by another
package.
I don't think there's anything wrong with this macro. CXXFLAGS should be
used both for compiling and linking. At least this is what GNU make do
by default:
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110401124749.GA517@jwilk.net">http://lists.debian.org/20110401124749.GA517@jwilk.net
On 31.03.2011 22:16, Jakub Wilk wrote:
>> You do need -lgomp.
>
> You normally don't (need to) link to gomp explicitly. My wild guess is:
> Dmitry used -fopenmp while compiling *.o, but not when linking the
> shared library.
Exactly! Thank you, Jakub, for nice guess.
AC_OPENMP() macro documentation looks to be a bit incomplete (e.g. if it
provides $OPENMP_LDFLAGS I wouldn't mess things), so I believe the
correct sequence looks like this:
On 01.04.2011 14:47, Jakub Wilk wrote:
> I don't think there's anything wrong with this macro. CXXFLAGS should be
> used both for compiling and linking. At least this is what GNU make do
> by default:
>
> $ make -p 2>/dev/null | grep 'LINK.cc = '
> LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
Thank you! It looks like I need to use $(LINK.cc) to link the .so library.
I also was suggested this resource:
> http://wiki.debian.org/ToolChain/DSOLinking#Unresolved_symbols_in_shared_libraries
which explains that this warning is raised, when the dependency chain is
like "A -> B -> C", and A needs symbols from C, but has no direct
dependency "A -> C" (which should be introduced as Brian also mentioned).
Thanks a lot for help to everyone!
--
With best regards,
Dmitry
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D9ACF08.4010001@mail.ru">http://lists.debian.org/4D9ACF08.4010001@mail.ru