Bug 25155 - libctf directory doesn't compile with MinGW
Summary: libctf directory doesn't compile with MinGW
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: libctf (show other bugs)
Version: 2.33
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-02 13:03 UTC by Eli Zaretskii
Modified: 2020-02-01 11:29 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Proposed patch to fix the problems with MinGW compilation (791 bytes, patch)
2019-12-24 16:17 UTC, Eli Zaretskii
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eli Zaretskii 2019-11-02 13:03:20 UTC
Building Binutils 2.33.1 with mingw.org's MinGW fails in the libctf directory due to several minor problems.

1. Compilation warning in ctf-dump.c:

     mingw32-gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.33.1/libctf  -D_GNU_SOURCE -I../../binutils-2.33.1/libctf -I../../binutils-2.33.1/libctf/../include -I../../binutils-2.33.1/libctf/../bfd -I../bfd   -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long   -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -MT ctf-dump.o -MD -MP -MF .deps/ctf-dump.Tpo -c -o ctf-dump.o ../
     ../binutils-2.33.1/libctf/ctf-dump.c
     ../../binutils-2.33.1/libctf/ctf-dump.c: In function 'ctf_dump_format_type':
     ../../binutils-2.33.1/libctf/ctf-dump.c:118:8: warning: implicit declaration of function 'asprintf'; did you mean 'vasprintf'? [-Wimplicit-function-declaration]

	 if (asprintf (&bit, " %lx: [slice 0x%x:0x%x]",
	     ^~~~~~~~
	     vasprintf

   This is because libctf/config.h doesn't have HAVE_DECL_ASPRINTF, as the other config.h files do.  And libiberty.h uses the following guard for the asprintf declaration:

#if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF
/* Like sprintf but provides a pointer to malloc'd storage, which must
   be freed by the caller.  */

extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;
#endif

2. Compilation error in ctf-create.c:

     mingw32-gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.33.1/libctf  -D_GNU_SOURCE -I../../binutils-2.33.1/libctf -I../../binutils-2.33.1/libctf/../include -I../../binutils-2.33.1/libctf/../bfd -I../bfd   -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long   -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -MT ctf-create.o -MD -MP -MF .deps/ctf-create.Tpo -c -o ctf-create.o ../../binutils-2.33.1/libctf/ctf-create.c
     ../../binutils-2.33.1/libctf/ctf-create.c: In function 'ctf_add_function':
     ../../binutils-2.33.1/libctf/ctf-create.c:950:32: error: 'EOVERFLOW' undeclared (first use in this function); did you mean 'EI_VERSION'?
	  return (ctf_set_errno (fp, EOVERFLOW));
				     ^~~~~~~~~
				     EI_VERSION

I fixed this by adding

     #ifndef EOVERFLOW
     # define EOVERFLOW ERANGE
     #endif

to ctf-create.c.  ERANGE is not exactly EOVERFLOW, but it's close enough.

3. Compilation error in ctf-subr.c:

     mingw32-gcc -DHAVE_CONFIG_H -I. -I../../binutils-2.33.1/libctf  -D_GNU_SOURCE -I../../binutils-2.33.1/libctf -I../../binutils-2.33.1/libctf/../include -I../../binutils-2.33.1/libctf/../bfd -I../bfd   -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long   -O2 -gdwarf-4 -g3 -D__USE
     _MINGW_ACCESS -MT ctf-subr.o -MD -MP -MF .deps/ctf-subr.Tpo -c -o ctf-subr.o ../
     ../binutils-2.33.1/libctf/ctf-subr.c
     ../../binutils-2.33.1/libctf/ctf-subr.c: In function 'ctf_version':
     ../../binutils-2.33.1/libctf/ctf-subr.c:159:12: error: 'ENOTSUP' undeclared (first use in this function); did you mean 'ENOTTY'?
	 errno = ENOTSUP;
		 ^~~~~~~
		 ENOTTY
     ../../binutils-2.33.1/libctf/ctf-subr.c:159:12: note: each undeclared identifier is reported only once for each function it appears in

I fixed this by adding

     #ifndef ENOTSUP
     # define ENOTSUP ENOSYS
     #endif

at the beginning of ctf-subr.c.

Thank you for developing Binutils.
Comment 1 Eli Zaretskii 2019-12-24 16:17:48 UTC
Created attachment 12146 [details]
Proposed patch to fix the problems with MinGW compilation

To perhaps expedite the fix of the MinGW build problems, I propose a patch in the attachment.

Thank you.
Comment 2 Nick Alcock 2020-01-03 16:43:01 UTC
Thank you! (And sorry for not noticing this bug flying by.)

I'm looking at this now (see recent traffic on the mailing list). All the patches Joel has proposed look good, but I think I have a way to fix the E* class of problems for all time, at the cost of a slight API break affecting no existing users (see the RFC patch I just posted).
Comment 3 cvs-commit@gcc.gnu.org 2020-01-05 05:51:38 UTC
The master branch has been updated by Joel Brobecker <brobecke@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3a657c600bde2d3bd84870f75968622bbdb69ce8

commit 3a657c600bde2d3bd84870f75968622bbdb69ce8
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sun Jan 5 09:50:27 2020 +0400

    libctf: Add configure check for asprintf (for MinGW)
    
    This commit fixes a compilation warning when compiling libctf
    on MinGW:
    
        libctf/ctf-dump.c:118:8: warning: implicit declaration of function
        'asprintf'; did you mean 'vasprintf'? [-Wimplicit-function-declaration]
    
    	 if (asprintf (&bit, " %lx: [slice 0x%x:0x%x]",
    	     ^~~~~~~~
    	     vasprintf
    
    MinGW doesn't provide that function, so we depend on the one provided
    by libiberty. However, the declaration is guarded by HAVE_DECL_ASPRINTF,
    which we do not have in libctf's config.h.
    
    libctf/ChangeLog:
    
    	PR binutils/25155:
    	* configure.ac: Add AC_CHECK_DECLS([asprintf]).
    	* configure, config.h.in: Regenerate.
Comment 4 cvs-commit@gcc.gnu.org 2020-01-05 06:12:30 UTC
The gdb-9-branch branch has been updated by Joel Brobecker <brobecke@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=84baa6a51500a6e6faf422ab12f61c5c9857cfd0

commit 84baa6a51500a6e6faf422ab12f61c5c9857cfd0
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sun Jan 5 09:50:27 2020 +0400

    libctf: Add configure check for asprintf (for MinGW)
    
    This commit fixes a compilation warning when compiling libctf
    on MinGW:
    
        libctf/ctf-dump.c:118:8: warning: implicit declaration of function
        'asprintf'; did you mean 'vasprintf'? [-Wimplicit-function-declaration]
    
    	 if (asprintf (&bit, " %lx: [slice 0x%x:0x%x]",
    	     ^~~~~~~~
    	     vasprintf
    
    MinGW doesn't provide that function, so we depend on the one provided
    by libiberty. However, the declaration is guarded by HAVE_DECL_ASPRINTF,
    which we do not have in libctf's config.h.
    
    libctf/ChangeLog:
    
    	PR binutils/25155:
    	* configure.ac: Add AC_CHECK_DECLS([asprintf]).
    	* configure, config.h.in: Regenerate.
    
    (cherry picked from commit 3a657c600bde2d3bd84870f75968622bbdb69ce8)
Comment 5 cvs-commit@gcc.gnu.org 2020-02-01 11:29:13 UTC
The gdb-9-branch branch has been updated by Joel Brobecker <brobecke@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=50500ecfefd6acc4c7f6c2a95bc0ae1945103220

commit 50500ecfefd6acc4c7f6c2a95bc0ae1945103220
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sat Feb 1 15:25:19 2020 +0400

    libctf: compilation failure on MinGW due to missing errno values
    
    This commit fixes a compilation failure in a couple of libctf files
    due to the use of EOVERFLOW and ENOTSUP, which are not defined
    when compiling on MinGW.
    
    libctf/ChangeLog:
    
    	PR binutils/25155:
    	* ctf-create.c (EOVERFLOW): If not defined by system header,
    	redirect to ERANGE as a poor man's substitute.
    	* ctf-subr.c (ENOTSUP): If not defined, use ENOSYS instead.
    
    This one is how Eli implemented it. I think this implementation
    has a weakness in the following sense: If other units in libctf
    start using those constants, we'll get the same error again.
    Also, I'm wondering whether their use is documented as part of
    the official libtcf API or not -- users might be writing code
    that tests for these, and if the system doesn't support them,
    how would they know what errno code to use in its place. This
    argues for a having that information in one of libctf's header
    files. I think it would be nice to have those in ctf-decls.h,
    but I think we'll need to include <errno.h> in ctf-decls.h if
    we decide to define those macros there.
    
    Rather than second-guess what the CTF developers would prefer,
    I'm starting by sending Eli's patch, to see what you guys think.
    
    Thanks,
    --
    Joel