devkitPro / buildscripts

Scripts for building devkitPro toolchains
http://devkitpro.org/
159 stars 40 forks source link

Error building dfu-util #2

Closed dacox closed 7 years ago

dacox commented 9 years ago

Hello, I am using the most recent release, v20150216, to build devkitArm.

When it gets to compiling dfu-util, I get the following error

In file included from main.c:34:0:
portable.h:17:17: fatal error: io.h: No such file or directory
 # include <io.h>

I believe I have installed all of the dependencies, and have installed the dependencies from http://dfu-util.sourceforge.net/build.html

Here is my config.sh for reference:

#!/bin/sh

BUILD_DKPRO_PACKAGE=1
BUILD_DKPRO_INSTALLDIR=/opt/devkitpro2
BUILD_DKPRO_AUTOMATED=1

Edit:

Seeing that the toolchain compiles fresh versions of gcc, I suspect that it might be a problem with the --libdir and --includedir for configuring dfu-util, but was wondering if anyone else was experiencing this

Kingwad commented 8 years ago

I get the same issue. I am building on a Debian Jessie system with gcc 4.9.2, if that helps with tracking this down.

make[1]: Entering directory '/home/zomnut/build/buildscripts/.devkitARM/dfu-util-0.8.1'
Making all in src
make[2]: Entering directory '/home/zomnut/build/buildscripts/.devkitARM/dfu-util-0.8.1/src'
  CC     main.o
In file included from main.c:34:0:
portable.h:17:17: fatal error: io.h: No such file or directory
 # include <io.h>
                 ^
compilation terminated.
Makefile:334: recipe for target 'main.o' failed

Failing code snippet in portable.h

#ifdef HAVE_FTRUNCATE
# include <unistd.h>
#else
# include <io.h>
#endif /* HAVE_FTRUNCATE */
carstene1ns commented 8 years ago

@dacox: The compiled gcc is only for the target software, dfu-util is run on the host, so it does not interfere here.

The header file of the dfu-util package tries to guess which system it is build on. If it is a POSIX compatible system, it should include the unistd header and under MSVC (Windows) it would include the io header. However, this check is broken, as it does assume every POSIX system has the ftruncate function (which is not true for you). Funny thing is, it is not even used afterwards...

I think what could be done is changing the check so it uses HAVE_UNISTD_H, this would be safe because autotools detect if the unistd header is available and MSVC does not define it. However, as dfu-util is external software this really should be fixed upstream. I am going to open a bug report and link this issue here.

Kingwad commented 8 years ago

Thanks @carstene1ns. I'm adding a link here to the dfu-util bug report for reference. http://sourceforge.net/p/dfu-util/tickets/9/

carstene1ns commented 8 years ago

This has been fixed upstream, so now we only need to wait for updated tarballs.

WinterMute commented 7 years ago

Finally sorted a release with the upstream update. :)