Hi Kevin,

This issue tends to happen if you are using a version of newt that is
incompatible with your core repo.  You mentioned you are using the
master branch of core; is it possible that you are using develop of the
newt repo?

Specifically, I think this issue is caused by this commit from last
week (newt repo): 0241d2f38e8236f03d6f20d5c7198d4a0a4cb169

I mentioned in an email last week that newt and core would need to be
upgraded together after this change.  Emails like that aren't
particularly useful, because they are only interesting to people who are
already experiencing issues!

One feature that newt needs is the ability to require minimum versions
of the core repo.  Then, compatibility-breaking changes would still be a
nuissance, but at least it would be obvious what the problem is.

Chris

On Mon, Dec 05, 2016 at 06:11:24PM +0100, Kevin Townsend wrote:
> I was updating some local dev systems, and with a clean install and then 
> running 'newt install -v' we now get the following error when we try to 
> build the bootloader:
> 
> /LOCAL_FOLDER/repos/apache-mynewt-core/crypto/mbedtls/include/mbedtls/config.h:2522:10:
>  
> error: #include expects "FILENAME" or <FILENAME>
>   #include MBEDTLS_USER_CONFIG_FILE
>            ^
> 
> This is new, but unexpected since nothing has changed in the last week 
> or so in the master branch of the repo, and the last change to 'boot' 
> was 26 days ago so I'm not missing something in our local slightly 
> modified bootloader code.
> 
> Has something recently changed with the mbedtls library that I'm not 
> seeing quickly looking at the git history in master?
> 
> Just commenting the offending line out causes problems elsewhere so 
> there seems to be a missing config file:
> 
> https://github.com/apache/incubator-mynewt-core/blob/master/crypto/mbedtls/include/mbedtls/config.h#L2522
> 
>     #if defined(YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE)
>     #include YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE
>     #elif defined(MBEDTLS_USER_CONFIG_FILE)
>     //#include MBEDTLS_USER_CONFIG_FILE
>     #endif
> 
> That just kicks the problems further down the field:
> 
>     ctr_drbg.c:425:5: error: implicit declaration of function 'fopen'
>     [-Werror=implicit-function-declaration]
>           if( ( f = fopen( path, "wb" ) ) == NULL )
>           ^
>     ctr_drbg.c:425:13: error: assignment makes pointer from integer
>     without a cast [-Werror]
>           if( ( f = fopen( path, "wb" ) ) == NULL )
>                   ^
>     ctr_drbg.c:440:5: error: implicit declaration of function 'fclose'
>     [-Werror=implicit-function-declaration]
>           fclose( f );
>           ^
>     ctr_drbg.c: In function 'mbedtls_ctr_drbg_update_seed_file':
>     ctr_drbg.c:450:13: error: assignment makes pointer from integer
>     without a cast [-Werror]
>           if( ( f = fopen( path, "rb" ) ) == NULL )
>                   ^
>     ctr_drbg.c:453:5: error: implicit declaration of function 'fseek'
>     [-Werror=implicit-function-declaration]
>           fseek( f, 0, SEEK_END );
>           ^
>     ctr_drbg.c:453:18: error: 'SEEK_END' undeclared (first use in this
>     function)
>           fseek( f, 0, SEEK_END );
>                        ^
>     ctr_drbg.c:453:18: note: each undeclared identifier is reported only
>     once for each function it appears in
>     ctr_drbg.c:454:5: error: implicit declaration of function 'ftell'
>     [-Werror=implicit-function-declaration]
>           n = (size_t) ftell( f );
>           ^
>     ctr_drbg.c:455:18: error: 'SEEK_SET' undeclared (first use in this
>     function)
>           fseek( f, 0, SEEK_SET );
>                        ^
>     cc1: all warnings being treated as errors
> 
> Any idea what might be causing the issue here? I'm looking at the 
> mbedtls source and don't see any recent pushes there, etc.
> 

Reply via email to