From: Michael G. <mic...@gm...> - 2013-11-03 03:23:53
|
Hi, After upgrading my MinGW installation I started to get weird undefined reference to cabsf and cabsl. To be sure, I reinstalled MinGW from scratch (into a different directory) using the graphical installer (0.6.2). I then tried to compile the following test program: #include <math.h> #include <complex.h> #include <stdio.h> int main (int argc, char **argv) { float complex x = 1 + 1*I; double complex y = 1 + 1*I; printf ("%g\n", cabsf (x)); printf ("%g\n", cabs (y)); return 0; } I then try to compile it as follows: $ gcc -Wall -o test-cabsf test-cabsf.c -lm C:\DOCUME~1\goffioul\LOCALS~1\Temp\ccSz5blq.o:test-cabsf.c:(.text+0x44): undefined reference to `cabsf' collect2.exe: error: ld returned 1 exit status AFAIK this used to be in libmingwex.a, I could verify it by using "nm" on that library from the old version of the mingwrt archive I still had in cache (3.20-2). However the same library from the newer mingwrt (4.0.3) does not contain it. Is it a packaging bug, or have those functions been removed from the runtime libraries (or moved elsewhere)? Michael. |
From: Michael G. <mic...@gm...> - 2013-11-03 03:49:25
|
On Sat, Nov 2, 2013 at 11:23 PM, Michael Goffioul < mic...@gm...> wrote: > Hi, > > After upgrading my MinGW installation I started to get weird undefined > reference to cabsf and cabsl. To be sure, I reinstalled MinGW from scratch > (into a different directory) using the graphical installer (0.6.2). I then > tried to compile the following test program: > > #include <math.h> > #include <complex.h> > #include <stdio.h> > > int main (int argc, char **argv) > { > float complex x = 1 + 1*I; > double complex y = 1 + 1*I; > > printf ("%g\n", cabsf (x)); > printf ("%g\n", cabs (y)); > > return 0; > } > > I then try to compile it as follows: > > $ gcc -Wall -o test-cabsf test-cabsf.c -lm > C:\DOCUME~1\goffioul\LOCALS~1\Temp\ccSz5blq.o:test-cabsf.c:(.text+0x44): > undefined reference to `cabsf' > collect2.exe: error: ld returned 1 exit status > > AFAIK this used to be in libmingwex.a, I could verify it by using "nm" on > that library from the old version of the mingwrt archive I still had in > cache (3.20-2). However the same library from the newer mingwrt (4.0.3) > does not contain it. > > Is it a packaging bug, or have those functions been removed from the > runtime libraries (or moved elsewhere)? > As a follow-up, I've compared the file list for libmingwex.a in versions 3.20-1 and 4.0.3 of mingwrt and I noticed that the latter was missing all complex-related source files. If I may make a suggestion, I would suspect this line: http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/Makefile.in#l307 It looks fairly redundant with the previous complex_SOURCES definition and may not work properly when building out the source directory. Michael. |
From: Michael G. <mic...@gm...> - 2013-11-05 12:33:30
|
On Sat, Nov 2, 2013 at 11:49 PM, Michael Goffioul < mic...@gm...> wrote: > On Sat, Nov 2, 2013 at 11:23 PM, Michael Goffioul < > mic...@gm...> wrote: > >> Hi, >> >> After upgrading my MinGW installation I started to get weird undefined >> reference to cabsf and cabsl. To be sure, I reinstalled MinGW from scratch >> (into a different directory) using the graphical installer (0.6.2). I then >> tried to compile the following test program: >> >> #include <math.h> >> #include <complex.h> >> #include <stdio.h> >> >> int main (int argc, char **argv) >> { >> float complex x = 1 + 1*I; >> double complex y = 1 + 1*I; >> >> printf ("%g\n", cabsf (x)); >> printf ("%g\n", cabs (y)); >> >> return 0; >> } >> >> I then try to compile it as follows: >> >> $ gcc -Wall -o test-cabsf test-cabsf.c -lm >> C:\DOCUME~1\goffioul\LOCALS~1\Temp\ccSz5blq.o:test-cabsf.c:(.text+0x44): >> undefined reference to `cabsf' >> collect2.exe: error: ld returned 1 exit status >> >> AFAIK this used to be in libmingwex.a, I could verify it by using "nm" on >> that library from the old version of the mingwrt archive I still had in >> cache (3.20-2). However the same library from the newer mingwrt (4.0.3) >> does not contain it. >> >> Is it a packaging bug, or have those functions been removed from the >> runtime libraries (or moved elsewhere)? >> > > As a follow-up, I've compared the file list for libmingwex.a in versions > 3.20-1 and 4.0.3 of mingwrt and I noticed that the latter was missing all > complex-related source files. If I may make a suggestion, I would suspect > this line: > > > http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/Makefile.in#l307 > > It looks fairly redundant with the previous complex_SOURCES definition and > may not work properly when building out the source directory. > Is this the wrong list to report such problem? This looks like a serious issue to me. Can anybody reproduce the problem? Maybe the problem lies somewhere on my system, or the C99 complex functions have been moved to another library? Michael. |
From: Michael G. <mic...@gm...> - 2013-11-05 13:35:03
|
On Tue, Nov 5, 2013 at 7:52 AM, Sergio NNX <sfh...@ho...> wrote: > > Is this the wrong list to report such problem? This looks like a serious > issue to me. Can anybody reproduce the > > problem? Maybe the problem lies somewhere on my system, or the C99 > complex functions have been moved > > to another library? > > Ciao Micheal. > > I've just checked whether I have 'cabsf' function or not and I wasn't able > to find it. I checked libm.a and it's not there. > Under MinGW, it's never there :) libm.a is just a empty placeholder to make it more UNIX-like (e.g. autoconf tests will usually check for math functions in -lm). The functions are actually located into libmingwex.a, which is automatically linked in by GCC. The problem is that in the current version of mingw32-mingwrt package, libmingwex.a does not contain the C99 complex functions anymore, leading to compilation failures. > However, I replaced 'cabsf' with '_hypot' and it worked ok (maybe it's not > what you're looking for/need but ...) > Thanks. I'm not looking for a replacement. My problem is that problem leads to compilation/link failures when trying to recompile libgfortran. Michael. |
From: Diego C. <dca...@gm...> - 2013-11-06 03:12:01
|
I can confirm the issue, but it only occurs when no optimization options are used. Ie. gcc test.c -o test.exe .file "test.c" .def ___main; .scl 2; .type 32; .endef .section .rdata,"dr" LC2: .ascii "%g\12\0" .align 4 LC0: .long 1065353216 .long 1065353216 .align 8 LC1: .long 0 .long 1072693248 .long 0 .long 1072693248 .text .globl _main .def _main; .scl 2; .type 32; .endef _main: LFB18: .cfi_startproc pushl %ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl %esp, %ebp .cfi_def_cfa_register 5 andl $-16, %esp subl $48, %esp call ___main movl LC0, %eax movl %eax, 40(%esp) movl LC0+4, %eax movl %eax, 44(%esp) fldl LC1 fstpl 24(%esp) fldl LC1+8 fstpl 32(%esp) movl 40(%esp), %eax movl %eax, (%esp) movl 44(%esp), %eax movl %eax, 4(%esp) call _cabsf fstpl 4(%esp) movl $LC2, (%esp) call _printf fldl 24(%esp) fstpl (%esp) fldl 32(%esp) fstpl 8(%esp) call _cabs fstpl 4(%esp) movl $LC2, (%esp) call _printf movl $0, %eax leave .cfi_restore 5 .cfi_def_cfa 4, 4 ret .cfi_endproc LFE18: .ident "GCC: (GNU) 4.8.1" .def _cabsf; .scl 2; .type 32; .endef .def _printf; .scl 2; .type 32; .endef .def _cabs; .scl 2; .type 32; .endef While, gcc -O2 test.c -o test.exe .file "test.c" .def ___main; .scl 2; .type 32; .endef .section .rdata,"dr" LC1: .ascii "%g\12\0" .section .text.startup,"x" .p2align 4,,15 .globl _main .def _main; .scl 2; .type 32; .endef _main: LFB46: .cfi_startproc pushl %ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl %esp, %ebp .cfi_def_cfa_register 5 andl $-16, %esp subl $16, %esp call ___main movl $LC1, (%esp) flds LC0 fstpl 4(%esp) call _printf movl $LC1, (%esp) fldl LC2 fstpl 4(%esp) call _printf xorl %eax, %eax leave .cfi_restore 5 .cfi_def_cfa 4, 4 ret .cfi_endproc LFE46: .section .rdata,"dr" .align 4 LC0: .long 1068827891 .align 8 LC2: .long 1719614413 .long 1073127582 .ident "GCC: (GNU) 4.8.1" .def _printf; .scl 2; .type 32; .endef $ ./test.exe 1.41421 1.41421 Hope that brings some light, just my 2cents. 2013/11/5 Michael Goffioul <mic...@gm...>: > On Sat, Nov 2, 2013 at 11:49 PM, Michael Goffioul > <mic...@gm...> wrote: >> >> On Sat, Nov 2, 2013 at 11:23 PM, Michael Goffioul >> <mic...@gm...> wrote: >>> >>> Hi, >>> >>> After upgrading my MinGW installation I started to get weird undefined >>> reference to cabsf and cabsl. To be sure, I reinstalled MinGW from scratch >>> (into a different directory) using the graphical installer (0.6.2). I then >>> tried to compile the following test program: >>> >>> #include <math.h> >>> #include <complex.h> >>> #include <stdio.h> >>> >>> int main (int argc, char **argv) >>> { >>> float complex x = 1 + 1*I; >>> double complex y = 1 + 1*I; >>> >>> printf ("%g\n", cabsf (x)); >>> printf ("%g\n", cabs (y)); >>> >>> return 0; >>> } >>> >>> I then try to compile it as follows: >>> >>> $ gcc -Wall -o test-cabsf test-cabsf.c -lm >>> C:\DOCUME~1\goffioul\LOCALS~1\Temp\ccSz5blq.o:test-cabsf.c:(.text+0x44): >>> undefined reference to `cabsf' >>> collect2.exe: error: ld returned 1 exit status >>> >>> AFAIK this used to be in libmingwex.a, I could verify it by using "nm" on >>> that library from the old version of the mingwrt archive I still had in >>> cache (3.20-2). However the same library from the newer mingwrt (4.0.3) does >>> not contain it. >>> >>> Is it a packaging bug, or have those functions been removed from the >>> runtime libraries (or moved elsewhere)? >> >> >> As a follow-up, I've compared the file list for libmingwex.a in versions >> 3.20-1 and 4.0.3 of mingwrt and I noticed that the latter was missing all >> complex-related source files. If I may make a suggestion, I would suspect >> this line: >> >> >> http://sourceforge.net/p/mingw/mingw-org-wsl/ci/master/tree/Makefile.in#l307 >> >> It looks fairly redundant with the previous complex_SOURCES definition and >> may not work properly when building out the source directory. > > > Is this the wrong list to report such problem? This looks like a serious > issue to me. Can anybody reproduce the problem? Maybe the problem lies > somewhere on my system, or the C99 complex functions have been moved to > another library? > > Michael. > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette > may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
From: Michael G. <mic...@gm...> - 2013-11-06 04:12:32
|
On Tue, Nov 5, 2013 at 10:11 PM, Diego Casorran <dca...@gm...> wrote: > I can confirm the issue, but it only occurs when no optimization > options are used. > Thanks for checking it. However, I think the fact that it does not happen with -O2 is just an an artefact due to the fact that "x" variable is initialized with a constant value: I suppose the compiler than sees that it can precompute the result of cabsf(x) without needing to call cabsf. If you remove the initialization of "x" (e.g. only use "float complex x;"), then cabsf is used again, even with -O2 turned on. Michael. |
From: Michael G. <mic...@gm...> - 2013-11-06 14:34:57
|
On Tue, Nov 5, 2013 at 11:12 PM, Michael Goffioul < mic...@gm...> wrote: > On Tue, Nov 5, 2013 at 10:11 PM, Diego Casorran <dca...@gm...>wrote: > >> I can confirm the issue, but it only occurs when no optimization >> options are used. >> > > Thanks for checking it. However, I think the fact that it does not happen > with -O2 is just an an artefact due to the fact that "x" variable is > initialized with a constant value: I suppose the compiler than sees that it > can precompute the result of cabsf(x) without needing to call cabsf. If you > remove the initialization of "x" (e.g. only use "float complex x;"), then > cabsf is used again, even with -O2 turned on. > For the record, the only solution at the moment is to downgrade to: - mingw32-mingwrt=3.20-1 - mingw32-w32api=3.17-2 Hopefully, this bug will be fixed in future releases of MinGW. Michael. |