Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Trying to disable error=format-security for clapack
1,405 views
Skip to first unread message
Andreas Tille
May 16, 2016, 5:10:03 AM5/16/16
to
Hi,
as a precondition for some package for Debian Med I intend to package
clapack[1]. Despite the discussion on Debian Science about the relation
of clapack and lapacke[2] I decided that it is less effort to have
clapack in addition since upstream of phast[3] (my final target) does
not intend to port the code from clapack to lapacke.
I tried to build clapack[1] and it has a nasty format error:
/build/clapack-3.2.1/F2CLIBS/libf2c/arithchk.c:125:2: error: format not a string literal and no format arguments [-Werror=format-security]
Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;
^
cc1: some warnings being treated as errors
When reading the code it seems to me that actually a test whether this
code works or not is intended and thus fixing the format is not in the
intention of the authors. So I tried
export DEB_BUILD_HARDENING_FORMAT:=0
DPKG_EXPORT_BUILDFLAGS = 1
but the build keeps on failing. Any idea?
Kind regards
Andreas.
[1] https://anonscm.debian.org/git/debian-science/packages/clapack.git
[2] https://lists.debian.org/debian-science/2016/04/msg00053.html
[3] https://anonscm.debian.org/git/debian-med/phast.git
--
http://fam-tille.de
as a precondition for some package for Debian Med I intend to package
clapack[1]. Despite the discussion on Debian Science about the relation
of clapack and lapacke[2] I decided that it is less effort to have
clapack in addition since upstream of phast[3] (my final target) does
not intend to port the code from clapack to lapacke.
I tried to build clapack[1] and it has a nasty format error:
/build/clapack-3.2.1/F2CLIBS/libf2c/arithchk.c:125:2: error: format not a string literal and no format arguments [-Werror=format-security]
Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;
^
cc1: some warnings being treated as errors
When reading the code it seems to me that actually a test whether this
code works or not is intended and thus fixing the format is not in the
intention of the authors. So I tried
export DEB_BUILD_HARDENING_FORMAT:=0
DPKG_EXPORT_BUILDFLAGS = 1
but the build keeps on failing. Any idea?
Kind regards
Andreas.
[1] https://anonscm.debian.org/git/debian-science/packages/clapack.git
[2] https://lists.debian.org/debian-science/2016/04/msg00053.html
[3] https://anonscm.debian.org/git/debian-med/phast.git
--
http://fam-tille.de
Sebastiaan Couwenberg
May 16, 2016, 5:20:02 AM5/16/16
to
On 05/16/2016 11:07 AM, Andreas Tille wrote:
> When reading the code it seems to me that actually a test whether this
> code works or not is intended and thus fixing the format is not in the
> intention of the authors. So I tried
>
> export DEB_BUILD_HARDENING_FORMAT:=0
> DPKG_EXPORT_BUILDFLAGS = 1
>
> but the build keeps on failing. Any idea?
If you want to disable the format-security option, you can try this in
> When reading the code it seems to me that actually a test whether this
> code works or not is intended and thus fixing the format is not in the
> intention of the authors. So I tried
>
> export DEB_BUILD_HARDENING_FORMAT:=0
> DPKG_EXPORT_BUILDFLAGS = 1
>
> but the build keeps on failing. Any idea?
debian/rules:
CFLAGS += -Wno-error=format-security
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Gianfranco Costamagna
May 16, 2016, 5:20:02 AM5/16/16
to
Hi,
>/build/clapack-3.2.1/F2CLIBS/libf2c/arithchk.c:125:2: error: format not a string literal and no format arguments [-Werror=format-security]
> Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;
> ^
>cc1: some warnings being treated as errors
I would consider this an RC bug.
security wise the printf can be used to inject shell code in the program, so I would avoid having such buggyness in the archive
[1] https://en.wikipedia.org/wiki/Uncontrolled_format_string
char *emptyfmt = ""; /* avoid possible warning message with printf("") */
printf(emptyfmt);
should be replaced with
char *emptyfmt = ""; /* avoid possible warning message with printf("") */
printf("%s",emptyfmt);
I'm not sure why you don't want to cherry such a simple and safe fix.
G.
>/build/clapack-3.2.1/F2CLIBS/libf2c/arithchk.c:125:2: error: format not a string literal and no format arguments [-Werror=format-security]
> Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;
> ^
>cc1: some warnings being treated as errors
security wise the printf can be used to inject shell code in the program, so I would avoid having such buggyness in the archive
[1] https://en.wikipedia.org/wiki/Uncontrolled_format_string
char *emptyfmt = ""; /* avoid possible warning message with printf("") */
printf(emptyfmt);
should be replaced with
char *emptyfmt = ""; /* avoid possible warning message with printf("") */
printf("%s",emptyfmt);
I'm not sure why you don't want to cherry such a simple and safe fix.
G.
Mattia Rizzolo
May 16, 2016, 5:30:02 AM5/16/16
to
On Mon, May 16, 2016 at 11:11:54AM +0200, Sebastiaan Couwenberg wrote:
> On 05/16/2016 11:07 AM, Andreas Tille wrote:
> > When reading the code it seems to me that actually a test whether this
> > code works or not is intended and thus fixing the format is not in the
> > intention of the authors. So I tried
> >
> > export DEB_BUILD_HARDENING_FORMAT:=0
> > DPKG_EXPORT_BUILDFLAGS = 1
DPKG_EXPORT_BUILDFLAGS is a thing only if you include
> On 05/16/2016 11:07 AM, Andreas Tille wrote:
> > When reading the code it seems to me that actually a test whether this
> > code works or not is intended and thus fixing the format is not in the
> > intention of the authors. So I tried
> >
> > export DEB_BUILD_HARDENING_FORMAT:=0
> > DPKG_EXPORT_BUILDFLAGS = 1
/usr/share/dpkg/buildflags.mk, and anyway already done by debhelper in
compat level 9.
Dunno what DEB_BUILD_HARDENING_FORMAT is.
> >
> > but the build keeps on failing. Any idea?
>
> If you want to disable the format-security option, you can try this in
> debian/rules:
>
> CFLAGS += -Wno-error=format-security
flags is added by dpkg-buildflags in first place) instead. See
dpkg-buildflags(1).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Niels Thykier
May 16, 2016, 5:40:02 AM5/16/16
to
Mattia Rizzolo:
I believe hardening-wrapper subscribed to DEB_BUILD_HARDENING_* flags
like the one above.
Thanks,
~Niels
> On Mon, May 16, 2016 at 11:11:54AM +0200, Sebastiaan Couwenberg wrote:
>> On 05/16/2016 11:07 AM, Andreas Tille wrote:
>>> When reading the code it seems to me that actually a test whether this
>>> code works or not is intended and thus fixing the format is not in the
>>> intention of the authors. So I tried
>>>
>>> export DEB_BUILD_HARDENING_FORMAT:=0
>>> DPKG_EXPORT_BUILDFLAGS = 1
>
> DPKG_EXPORT_BUILDFLAGS is a thing only if you include
> /usr/share/dpkg/buildflags.mk, and anyway already done by debhelper in
> compat level 9.
> Dunno what DEB_BUILD_HARDENING_FORMAT is.
>
>>> [...]
>> On 05/16/2016 11:07 AM, Andreas Tille wrote:
>>> When reading the code it seems to me that actually a test whether this
>>> code works or not is intended and thus fixing the format is not in the
>>> intention of the authors. So I tried
>>>
>>> export DEB_BUILD_HARDENING_FORMAT:=0
>>> DPKG_EXPORT_BUILDFLAGS = 1
>
> DPKG_EXPORT_BUILDFLAGS is a thing only if you include
> /usr/share/dpkg/buildflags.mk, and anyway already done by debhelper in
> compat level 9.
> Dunno what DEB_BUILD_HARDENING_FORMAT is.
>
I believe hardening-wrapper subscribed to DEB_BUILD_HARDENING_* flags
like the one above.
Thanks,
~Niels
Gert Wollny
May 16, 2016, 6:10:02 AM5/16/16
to
Hello,
Am Montag, den 16.05.2016, 09:14 +0000 schrieb Gianfranco Costamagna:
> Hi,
>
> > /build/clapack-3.2.1/F2CLIBS/libf2c/arithchk.c:125:2: error: format
> > not a string literal and no format arguments [-Werror=format-
> > security]
> > Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;
> > ^
> > cc1: some warnings being treated as errors
>
> I would consider this an RC bug.
>
> security wise the printf can be used to inject shell code in the
> program, so I would avoid having such buggyness in the archive
> [1] https://en.wikipedia.org/wiki/Uncontrolled_format_string
I think, since in this case the (empty) format string passed to the printf call is not user generated there is no security problem to be exploited.
In addition the source code file in question is part of the "check" target, so this piece of code will will only be using during building and not end up in a library.
>
> char *emptyfmt = ""; /* avoid possible warning message with
> printf("") */
> printf(emptyfmt);
>
> should be replaced with
>
> char *emptyfmt = ""; /* avoid possible warning message with
> printf("") */
> printf("%s",emptyfmt);
>
> I'm not sure why you don't want to cherry such a simple and safe fix.
The code seems to be using this call to do some wired checking on what
platform it is run, and I would guess that your fix would break this
check.
Considering that the variable is called Cray1 I would somehow guess
that this test actually finds out whether this code is running on a
Cray1 where floating point arithmetic seems to have some differences as
compared to IEEE floating point operations.
If Debian doesn't run on such an arch the test could most likely safely
be removed, i.e. remove all code from "ccheck" but the "return 0"
line.
Apart from that disabling the warning itself can and should be done in
the code by using pragmas like this:
#ifdef __GNUC__
# pragma GCC diagnostic push
# ifndef __clang__
# pragma GCC diagnostic ignored "-Wformat-security"
# else
# pragma clang diagnostic ignored "-Wformat-security"
# endif
#endif
/* code that issues warning */
#ifdef __GNUC__
# pragma GCC diagnostic pop
#endif
Hope that helps,
Gert
Am Montag, den 16.05.2016, 09:14 +0000 schrieb Gianfranco Costamagna:
> Hi,
>
> > /build/clapack-3.2.1/F2CLIBS/libf2c/arithchk.c:125:2: error: format
> > not a string literal and no format arguments [-Werror=format-
> > security]
> > Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;
> > ^
> > cc1: some warnings being treated as errors
>
> I would consider this an RC bug.
>
> security wise the printf can be used to inject shell code in the
> program, so I would avoid having such buggyness in the archive
> [1] https://en.wikipedia.org/wiki/Uncontrolled_format_string
In addition the source code file in question is part of the "check" target, so this piece of code will will only be using during building and not end up in a library.
>
> char *emptyfmt = ""; /* avoid possible warning message with
> printf("") */
> printf(emptyfmt);
>
> should be replaced with
>
> char *emptyfmt = ""; /* avoid possible warning message with
> printf("") */
> printf("%s",emptyfmt);
>
> I'm not sure why you don't want to cherry such a simple and safe fix.
platform it is run, and I would guess that your fix would break this
check.
Considering that the variable is called Cray1 I would somehow guess
that this test actually finds out whether this code is running on a
Cray1 where floating point arithmetic seems to have some differences as
compared to IEEE floating point operations.
If Debian doesn't run on such an arch the test could most likely safely
be removed, i.e. remove all code from "ccheck" but the "return 0"
line.
Apart from that disabling the warning itself can and should be done in
the code by using pragmas like this:
#ifdef __GNUC__
# pragma GCC diagnostic push
# ifndef __clang__
# pragma GCC diagnostic ignored "-Wformat-security"
# else
# pragma clang diagnostic ignored "-Wformat-security"
# endif
#endif
/* code that issues warning */
#ifdef __GNUC__
# pragma GCC diagnostic pop
#endif
Hope that helps,
Gert
Gianfranco Costamagna
May 16, 2016, 6:20:03 AM5/16/16
to
Hi Gert!
>I think, since in this case the (empty) format string passed to the printf call is not user generated there is no security problem to be exploited.
yes, sure, but disabling this flag has a nasty side-effect, it is disabled in the *whole* build, possibly
hiding more serious issues somewhere else.
I would prefer disabling that test, rather than disabling a security feature in the whole package.
BTW fedora packaged "F2CLIBS" separately from clapack, I'm not sure if worth a try or not, but it should be at least considered.
cheers,
G.
>I think, since in this case the (empty) format string passed to the printf call is not user generated there is no security problem to be exploited.
hiding more serious issues somewhere else.
I would prefer disabling that test, rather than disabling a security feature in the whole package.
BTW fedora packaged "F2CLIBS" separately from clapack, I'm not sure if worth a try or not, but it should be at least considered.
cheers,
G.
Gert Wollny
May 16, 2016, 6:30:02 AM5/16/16
to
Am Montag, den 16.05.2016, 10:16 +0000 schrieb Gianfranco Costamagna:
> Hi Gert!
>
> >
> > I think, since in this case the (empty) format string passed to the
> > printf call is not user generated there is no security problem to
> > be exploited.
>
> yes, sure, but disabling this flag has a nasty side-effect, it is
> disabled in the *whole* build, possibly
> hiding more serious issues somewhere else.
Of course, that's why I gave the #pragma based disabling that can be
> Hi Gert!
>
> >
> > I think, since in this case the (empty) format string passed to the
> > printf call is not user generated there is no security problem to
> > be exploited.
>
> yes, sure, but disabling this flag has a nasty side-effect, it is
> disabled in the *whole* build, possibly
> hiding more serious issues somewhere else.
fitted tightly to the offending code.
Best,
Gert
Jakub Wilk
May 16, 2016, 6:30:02 AM5/16/16
to
* Gert Wollny <gw.fo...@gmail.com>, 2016-05-16, 12:02:
always works on Debian.
Contrary to what the comment says, the current ccheck() implementation
does cause signed integer overflow on 32-bit architectures, which is
undefined behavior. So yes, please patch out this code...
--
Jakub Wilk
>If Debian doesn't run on such an arch the test could most likely safely
>be removed, i.e. remove all code from "ccheck" but the "return 0"
>line.
This is what I would recommend. It's safe to assume that printf("")
>be removed, i.e. remove all code from "ccheck" but the "return 0"
>line.
always works on Debian.
Contrary to what the comment says, the current ccheck() implementation
does cause signed integer overflow on 32-bit architectures, which is
undefined behavior. So yes, please patch out this code...
--
Jakub Wilk
Danny Edel
May 16, 2016, 8:10:02 AM5/16/16
to
On 05/16/2016 11:07 AM, Andreas Tille wrote:
> /build/clapack-3.2.1/F2CLIBS/libf2c/arithchk.c:125:2: error: format not a string literal and no format arguments [-Werror=format-security]
> Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;
Hi Andreas,
> Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;
you should have success with changing the type (insted of the value) of
emptyfmt, rather than disabling any warnings.
Right now it's "char *", which is legal C, but problematic, since
character literals are not allowed to be written to anyway and might
even be placed in read-only memory[1]. Just the type "readwrite pointer
to readwrite character" probably triggers the warning.
If you change it to "const char* const", the compiler is assured it's
never going to point to anything else and does not emit the warning.
Cheers,
- Danny
[1]: http://en.cppreference.com/w/c/language/string_literal
Danny Edel
May 16, 2016, 10:40:02 AM5/16/16
to
On 05/16/2016 01:50 PM, Danny Edel wrote:
> If you change it to "const char* const", the compiler is assured it's
> never going to point to anything else and does not emit the warning.
Sorry for replying to my own email, but after compiling, the test suite
> If you change it to "const char* const", the compiler is assured it's
> never going to point to anything else and does not emit the warning.
crashed on the xeigtstz_* with Segmentation Fault errors.
I debugged this a little bit and the reason was these tests use a lot of
local (i.e. stack) variables -- so many in fact that they trigger a
stack overflow on entry.
Disabling stack size limit (mine was 8192 KB) with
ulimit -s unlimited
before calling dpkg-buildpackage fixed things for me.
I hope this avoids someone the half hour I spent in gdb searching for a
bug that probably isn't there.
- Danny
Andreas Tille
May 16, 2016, 12:30:03 PM5/16/16
to
Hi Danny,
On Mon, May 16, 2016 at 04:30:23PM +0200, Danny Edel wrote:
> Sorry for replying to my own email, but after compiling, the test suite
> crashed on the xeigtstz_* with Segmentation Fault errors.
No need to sorry,
> I debugged this a little bit and the reason was these tests use a lot of
> local (i.e. stack) variables -- so many in fact that they trigger a
> stack overflow on entry.
>
> Disabling stack size limit (mine was 8192 KB) with
> ulimit -s unlimited
> before calling dpkg-buildpackage fixed things for me.
>
> I hope this avoids someone the half hour I spent in gdb searching for a
> bug that probably isn't there.
Would you mind commiting to Git what was building for you?
Kind regards and thanks for your review
Andreas.
--
http://fam-tille.de
On Mon, May 16, 2016 at 04:30:23PM +0200, Danny Edel wrote:
> Sorry for replying to my own email, but after compiling, the test suite
> crashed on the xeigtstz_* with Segmentation Fault errors.
> I debugged this a little bit and the reason was these tests use a lot of
> local (i.e. stack) variables -- so many in fact that they trigger a
> stack overflow on entry.
>
> Disabling stack size limit (mine was 8192 KB) with
> ulimit -s unlimited
> before calling dpkg-buildpackage fixed things for me.
>
> I hope this avoids someone the half hour I spent in gdb searching for a
> bug that probably isn't there.
Kind regards and thanks for your review
Andreas.
--
http://fam-tille.de
Danny Edel
May 16, 2016, 1:30:08 PM5/16/16
to
On 05/16/2016 06:25 PM, Andreas Tille wrote:
>
> Would you mind commiting to Git what was building for you?
>
Hi Andreas,
>
> Would you mind commiting to Git what was building for you?
>
I would love to, but I doubt it's possible. I tried something along the
lines of "ulimit -s unlimited && dh_auto_test" as an
override_dh_auto_test, but depending on the environment (local vs.
cowbuilder vs. sbuild) this ulimit call would fail with "Operation not
permitted".
In case of cowbuilder or sbuild, it only works if I unlimited from the
shell I started the builder with, so putting any command inside the
debian/ wouldn't do anything.
The important question is if a stack-size-limit is active on the buildds
or maybe they're already unlimited. I would suggest packing as-is (only
with the const-pointer change) and uploading to a debomatic, since I
think they're very close to the official buildds.
If it actually fails, I'd suggest coordinating with buildd-admins to
figure out the best way to communicate this requirement. The tests
don't actually need much memory, they just have a very unusual
stack-to-heap ratio.
Cheers,
- Danny
Andreas Tille
May 21, 2016, 12:10:03 PM5/21/16
to
Hi again,
after the build issues in clapack[1] were solved and I was even able to
create shared libraries I wonder how I can properly set a sensible
SONAME. I tried to do this via SET_TARGET_PROPERTIES but failed.
Another question is how I could link against the Debian packaged f2c
rather than building the one that comes with clapack upstream.
Any help would be welcome
Andreas.
[1] https://anonscm.debian.org/git/debian-science/packages/clapack.git
--
http://fam-tille.de
after the build issues in clapack[1] were solved and I was even able to
create shared libraries I wonder how I can properly set a sensible
SONAME. I tried to do this via SET_TARGET_PROPERTIES but failed.
Another question is how I could link against the Debian packaged f2c
rather than building the one that comes with clapack upstream.
Any help would be welcome
Andreas.
[1] https://anonscm.debian.org/git/debian-science/packages/clapack.git
http://fam-tille.de
Gianfranco Costamagna
May 22, 2016, 3:10:02 AM5/22/16
to
Hi,
>after the build issues in clapack[1] were solved and I was even able to
>create shared libraries I wonder how I can properly set a sensible
>SONAME. I tried to do this via SET_TARGET_PROPERTIES but failed.
this is what I did on ettercap
https://sources.debian.net/src/ettercap/1:0.8.2-2/src/CMakeLists.txt/#L213
it works, as long as you create the library with add_library I guess
>Another question is how I could link against the Debian packaged f2c
>rather than building the one that comes with clapack upstream.
I would say: remove the add_subdirectory (line 21)
and then:
1) create a "FindF2C.cmake" file and use it as helper
(that would be the best and upstreamable choice
you can find some examples in "ettercap/cmake/Modules/Find*"
2) just include_directories for helping it to find the .h file (if not in standard directory)
and target_link_libraries of the .so file.
G.
>after the build issues in clapack[1] were solved and I was even able to
>create shared libraries I wonder how I can properly set a sensible
>SONAME. I tried to do this via SET_TARGET_PROPERTIES but failed.
https://sources.debian.net/src/ettercap/1:0.8.2-2/src/CMakeLists.txt/#L213
it works, as long as you create the library with add_library I guess
>Another question is how I could link against the Debian packaged f2c
>rather than building the one that comes with clapack upstream.
and then:
1) create a "FindF2C.cmake" file and use it as helper
(that would be the best and upstreamable choice
you can find some examples in "ettercap/cmake/Modules/Find*"
2) just include_directories for helping it to find the .h file (if not in standard directory)
and target_link_libraries of the .so file.
G.
Andreas Tille
May 23, 2016, 6:30:02 AM5/23/16
to
Hi Gianfranco,
your very helpful hints helped me to get some steps forward. However,
its not finally done.
On Sun, May 22, 2016 at 06:48:36AM +0000, Gianfranco Costamagna wrote:
> >Another question is how I could link against the Debian packaged f2c
> >rather than building the one that comes with clapack upstream.
>
> I would say: remove the add_subdirectory (line 21)
> and then:
> 1) create a "FindF2C.cmake" file and use it as helper
> (that would be the best and upstreamable choice
> you can find some examples in "ettercap/cmake/Modules/Find*"
>
>
> 2) just include_directories for helping it to find the .h file (if not in standard directory)
> and target_link_libraries of the .so file.
I think the .h files are not a problem. With my recent changes in Git[1]
there is a problem with the linker when running the clapack test suite:
...
std.dir/dtrt03.c.o CMakeFiles/xlintstd.dir/dtrt05.c.o CMakeFiles/xlintstd.dir/dtrt06.c.o CMakeFiles/xlintstd.dir/dtzt01.c.o CMakeFiles/xlintstd.dir/dtzt02.c.o CMakeFiles/xlintstd.dir/dgennd.c.o CMakeFiles/xlintstd.dir/ddrvge.c.o CMakeFiles/xlintstd.dir/ddrvgb.c.o CMakeFiles/xlintstd.dir/derrge.c.o CMakeFiles/xlintstd.dir/ddrvpo.c.o CMakeFiles/xlintstd.dir/derrpo.c.o CMakeFiles/xlintstd.dir/dlaord.c.o CMakeFiles/xlintstd.dir/__/__/INSTALL/dsecnd.c.o -o xlintstd -rdynamic ../MATGEN/libtmglib.a ../../SRC/libclapack.so.3.2.1 ../../BLAS/SRC/libcblas.so.3.2.1 -lm -lf2c -Wl,-rpath,/build/clapack-3.2.1/obj-x86_64-linux-gnu/SRC:/build/clapack-3.2.1/obj-x86_64-linux-gnu/BLAS/SRC
CMakeFiles/xlintstd.dir/alaerh.c.o: In function `alaerh_':
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:444: undefined reference to `i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:591: undefined reference to `i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:604: undefined reference to `i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:843: undefined reference to `i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:473: undefined reference to `i_len_trim'
CMakeFiles/xlintstd.dir/alaerh.c.o:/build/clapack-3.2.1/TESTING/LIN/alaerh.c:737: more undefined references to `i_len_trim' follow
CMakeFiles/xlintstd.dir/dchkps.c.o: In function `dchkps_':
/build/clapack-3.2.1/TESTING/LIN/dchkps.c:252: undefined reference to `i_dceiling'
collect2: error: ld returned 1 exit status
Any further hint?
--
http://fam-tille.de
your very helpful hints helped me to get some steps forward. However,
its not finally done.
On Sun, May 22, 2016 at 06:48:36AM +0000, Gianfranco Costamagna wrote:
> >Another question is how I could link against the Debian packaged f2c
> >rather than building the one that comes with clapack upstream.
>
> I would say: remove the add_subdirectory (line 21)
> and then:
> 1) create a "FindF2C.cmake" file and use it as helper
> (that would be the best and upstreamable choice
> you can find some examples in "ettercap/cmake/Modules/Find*"
>
>
> 2) just include_directories for helping it to find the .h file (if not in standard directory)
> and target_link_libraries of the .so file.
there is a problem with the linker when running the clapack test suite:
...
std.dir/dtrt03.c.o CMakeFiles/xlintstd.dir/dtrt05.c.o CMakeFiles/xlintstd.dir/dtrt06.c.o CMakeFiles/xlintstd.dir/dtzt01.c.o CMakeFiles/xlintstd.dir/dtzt02.c.o CMakeFiles/xlintstd.dir/dgennd.c.o CMakeFiles/xlintstd.dir/ddrvge.c.o CMakeFiles/xlintstd.dir/ddrvgb.c.o CMakeFiles/xlintstd.dir/derrge.c.o CMakeFiles/xlintstd.dir/ddrvpo.c.o CMakeFiles/xlintstd.dir/derrpo.c.o CMakeFiles/xlintstd.dir/dlaord.c.o CMakeFiles/xlintstd.dir/__/__/INSTALL/dsecnd.c.o -o xlintstd -rdynamic ../MATGEN/libtmglib.a ../../SRC/libclapack.so.3.2.1 ../../BLAS/SRC/libcblas.so.3.2.1 -lm -lf2c -Wl,-rpath,/build/clapack-3.2.1/obj-x86_64-linux-gnu/SRC:/build/clapack-3.2.1/obj-x86_64-linux-gnu/BLAS/SRC
CMakeFiles/xlintstd.dir/alaerh.c.o: In function `alaerh_':
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:444: undefined reference to `i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:591: undefined reference to `i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:604: undefined reference to `i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:843: undefined reference to `i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:473: undefined reference to `i_len_trim'
CMakeFiles/xlintstd.dir/alaerh.c.o:/build/clapack-3.2.1/TESTING/LIN/alaerh.c:737: more undefined references to `i_len_trim' follow
CMakeFiles/xlintstd.dir/dchkps.c.o: In function `dchkps_':
/build/clapack-3.2.1/TESTING/LIN/dchkps.c:252: undefined reference to `i_dceiling'
collect2: error: ld returned 1 exit status
Any further hint?
--
http://fam-tille.de
Gianfranco Costamagna
May 23, 2016, 6:40:03 AM5/23/16
to
http://ftp.kevag-telekom.de/mirrors/gentoo.org/rsync/sci-libs/clapack/files/clapack-3.2.1-noblasf2c.patch
seems that the i_len_trim.c file might be somewhere else, look at gentoo packaging, they seem to have not
stripped it from the tarball I guess.
Does this helps?
G.
seems that the i_len_trim.c file might be somewhere else, look at gentoo packaging, they seem to have not
stripped it from the tarball I guess.
Does this helps?
G.
Andreas Tille
May 23, 2016, 7:20:03 AM5/23/16
to
Sorry for replying to my own mail. I just noticed that the Debian
packaged libf2c really has no symbol i_len_trim. Will check what
version is packaged and how this can be fixed.
--
http://fam-tille.de
packaged libf2c really has no symbol i_len_trim. Will check what
version is packaged and how this can be fixed.
http://fam-tille.de
Andreas Tille
May 26, 2016, 7:20:02 AM5/26/16
to
Hi Gianfranco,
On Sun, May 22, 2016 at 06:48:36AM +0000, Gianfranco Costamagna wrote:
> ...
This involved adding two files missing in libf2c source which I took
over as a patch.
I can confirm that I builded several times on my local disk successfully
including the build time tests. At first this did not worked until I
made sure that Debian's default CFLAGS are also used for libf2c. Once I
have uploaded libf2c2 version 20130926-1 the build somehow stopped
working again. I can not even reproduce things with a local rebuild.
I always get something like:
...
Start 76: xeigtstd_lse_in
76/76 Test #76: xeigtstd_lse_in ..................***Failed 0.01 sec
Running: /home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/EIG//xeigtstd
ARGS= OUTPUT_FILE;/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/dlse.out;ERROR_FILE;/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/dlse.out.err;INPUT_FILE;/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/TESTING/lse.in
CMake Error at /home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/TESTING/runtest.cmake:29 (message):
Test
/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/EIG//xeigtstd
returned Segmentation fault
(for all the 76 tests not just the last one). Please note that I'm
skipping those tests mentioned by Danny Edel[1] inside the patch
skip_tests_triggering_stack_overflow.patch (see updated Git[2]).
So what I'd like to know: What's the difference between building the
code copy of libf2c comming with clapack (which can be proved by
deactivating use_debian_packaged_f2c.patch) and using libf2c2. (Bonus
question is what I have done differently when it worked here with local
builds of libf2c2 when it worked as well - but it might need more than
super power brain reading abilities. :-()
Any help would be welcome
Andreas.
[1] https://lists.debian.org/debian-mentors/2016/05/msg00406.html
[2] https://anonscm.debian.org/git/debian-science/packages/clapack.git
--
http://fam-tille.de
On Sun, May 22, 2016 at 06:48:36AM +0000, Gianfranco Costamagna wrote:
> I would say: remove the add_subdirectory (line 21)
> and then:
> 1) create a "FindF2C.cmake" file and use it as helper
> (that would be the best and upstreamable choice
> you can find some examples in "ettercap/cmake/Modules/Find*"
thanks to these hints I managed to build against Debian packaged libf2c.
> and then:
> 1) create a "FindF2C.cmake" file and use it as helper
> (that would be the best and upstreamable choice
> you can find some examples in "ettercap/cmake/Modules/Find*"
This involved adding two files missing in libf2c source which I took
over as a patch.
I can confirm that I builded several times on my local disk successfully
including the build time tests. At first this did not worked until I
made sure that Debian's default CFLAGS are also used for libf2c. Once I
have uploaded libf2c2 version 20130926-1 the build somehow stopped
working again. I can not even reproduce things with a local rebuild.
I always get something like:
...
Start 76: xeigtstd_lse_in
76/76 Test #76: xeigtstd_lse_in ..................***Failed 0.01 sec
Running: /home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/EIG//xeigtstd
ARGS= OUTPUT_FILE;/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/dlse.out;ERROR_FILE;/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/dlse.out.err;INPUT_FILE;/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/TESTING/lse.in
CMake Error at /home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/TESTING/runtest.cmake:29 (message):
Test
/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/EIG//xeigtstd
returned Segmentation fault
(for all the 76 tests not just the last one). Please note that I'm
skipping those tests mentioned by Danny Edel[1] inside the patch
skip_tests_triggering_stack_overflow.patch (see updated Git[2]).
So what I'd like to know: What's the difference between building the
code copy of libf2c comming with clapack (which can be proved by
deactivating use_debian_packaged_f2c.patch) and using libf2c2. (Bonus
question is what I have done differently when it worked here with local
builds of libf2c2 when it worked as well - but it might need more than
super power brain reading abilities. :-()
Any help would be welcome
Andreas.
[2] https://anonscm.debian.org/git/debian-science/packages/clapack.git
--
http://fam-tille.de
Gianfranco Costamagna
May 26, 2016, 7:40:03 AM5/26/16
to
Hi Andreas,
>o what I'd like to know: What's the difference between building the
>code copy of libf2c comming with clapack (which can be proved by
>deactivating use_debian_packaged_f2c.patch) and using libf2c2. (Bonus
I would look at both build logs and gcc versions.
maybe some new gcc compiler trigers some issues, or something different is happening there
(e.g. some part of the library built on 2013, with old gcc and the new one patches wit the new libstdc++)
or maybe something different, e.g. you are using two different library versions
I would try to copy the debian libf2c2 over the embedded one, and see with git diff if they are different.
if they are, try to copy and replace it over the embedded one, and see if with a debian dpkg-buildpackage build
you reproduce the issue.
(or try to debug the segfault)
cheers,
G.
>o what I'd like to know: What's the difference between building the
>code copy of libf2c comming with clapack (which can be proved by
>deactivating use_debian_packaged_f2c.patch) and using libf2c2. (Bonus
maybe some new gcc compiler trigers some issues, or something different is happening there
(e.g. some part of the library built on 2013, with old gcc and the new one patches wit the new libstdc++)
or maybe something different, e.g. you are using two different library versions
I would try to copy the debian libf2c2 over the embedded one, and see with git diff if they are different.
if they are, try to copy and replace it over the embedded one, and see if with a debian dpkg-buildpackage build
you reproduce the issue.
(or try to debug the segfault)
cheers,
G.
Gert Wollny
May 26, 2016, 10:30:02 AM5/26/16
to
Hello Andres,
> Once I have uploaded libf2c2 version 20130926-1 the build somehow
> stopped working again. I can not even reproduce things with a local
> rebuild.I always get something like:
In ./INCLUDE there is a f2c.h file that is not patched (unlike the
version of the system libf2c). The result is, that certain data types
in libf2c are assumed to be of type int (size=4), and with the
unpatched f2c.h file that is actually included when compiling clapack,
the same data type is long (8 byte).
Hence some data structures assume different sizes within the library
and on the callers side resulting in the segfault.
Removing the file INCLUDE/f2c.h solves the problem, because then the
system f2c.h will be used. (It may also be necessary to remove
F2CLIBS/f2c.h, I already deleted the whole directory before testing).
Best,
Gert
> Once I have uploaded libf2c2 version 20130926-1 the build somehow
> stopped working again. I can not even reproduce things with a local
>
> ...
> Start 76: xeigtstd_lse_in
> 76/76 Test #76: xeigtstd_lse_in ..................***Failed 0.01
> sec
Assuming you are on amd64:
> ...
> Start 76: xeigtstd_lse_in
> 76/76 Test #76: xeigtstd_lse_in ..................***Failed 0.01
> sec
In ./INCLUDE there is a f2c.h file that is not patched (unlike the
version of the system libf2c). The result is, that certain data types
in libf2c are assumed to be of type int (size=4), and with the
unpatched f2c.h file that is actually included when compiling clapack,
the same data type is long (8 byte).
Hence some data structures assume different sizes within the library
and on the callers side resulting in the segfault.
Removing the file INCLUDE/f2c.h solves the problem, because then the
system f2c.h will be used. (It may also be necessary to remove
F2CLIBS/f2c.h, I already deleted the whole directory before testing).
Best,
Gert
Andreas Tille
May 27, 2016, 11:10:03 AM5/27/16
to
Hi Gert,
On Thu, May 26, 2016 at 04:27:25PM +0200, Gert Wollny wrote:
> ...
This tip saved my evening yesterday - thanks a lot. The only remaining
issue is now
E: libclapack3: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libclapack.so.3.2.1 /build/clapack-3.2.1+dfsg/obj-x86_64-linux-gnu/BLAS/SRC
Is there any trick how I could tweak cmake files to prevent the
inclusion of rpath or is the only chance to solve this to use
chrpath --delete
?
Kind regards
Andreas.
--
http://fam-tille.de
On Thu, May 26, 2016 at 04:27:25PM +0200, Gert Wollny wrote:
> ...
> Removing the file INCLUDE/f2c.h solves the problem, because then the
> ...
This tip saved my evening yesterday - thanks a lot. The only remaining
issue is now
E: libclapack3: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libclapack.so.3.2.1 /build/clapack-3.2.1+dfsg/obj-x86_64-linux-gnu/BLAS/SRC
Is there any trick how I could tweak cmake files to prevent the
inclusion of rpath or is the only chance to solve this to use
chrpath --delete
?
Kind regards
Andreas.
--
http://fam-tille.de
Gianfranco Costamagna
May 27, 2016, 11:30:02 AM5/27/16
to
Hi,
> E: libclapack3: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libclapack.so.3.2.1 /build/clapack-3.2.1+dfsg/obj-x86_64-linux-gnu/BLAS/SRC
>Is there any trick how I could tweak cmake files to prevent the
>inclusion of rpath or is the only chance to solve this to use
>
> chrpath --delete
It shoulnd't be needed.
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE) might help, but by default somewhen in dh_install rpath should be removed
(debhelper?cmake?)
e.g. in ettercap I don't set it, and the cmake make install works beautifully.
Since we have an ettercap-text-only that we build and install in a custom way, we have to strip rpath on that file
https://buildd.debian.org/status/fetch.php?pkg=ettercap&arch=amd64&ver=1%3A0.8.2-2%2Bb1&stamp=1446812919
just search for something like:
INSTALL_RPATH ${INSTALL_LIBDIR})
this should be how in cmake they set the RPATH.
G.
> E: libclapack3: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libclapack.so.3.2.1 /build/clapack-3.2.1+dfsg/obj-x86_64-linux-gnu/BLAS/SRC
>Is there any trick how I could tweak cmake files to prevent the
>inclusion of rpath or is the only chance to solve this to use
>
> chrpath --delete
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE) might help, but by default somewhen in dh_install rpath should be removed
(debhelper?cmake?)
e.g. in ettercap I don't set it, and the cmake make install works beautifully.
Since we have an ettercap-text-only that we build and install in a custom way, we have to strip rpath on that file
https://buildd.debian.org/status/fetch.php?pkg=ettercap&arch=amd64&ver=1%3A0.8.2-2%2Bb1&stamp=1446812919
just search for something like:
INSTALL_RPATH ${INSTALL_LIBDIR})
this should be how in cmake they set the RPATH.
G.
0 new messages