I'm trying to install gcc on cygwyn using this tutorial. After this step $ make -j4 I'm facing lots of warnings:
^
../../gcc-4.9.2/gcc/asan.c:2012:11: warning: enumeration value ‘BUILT_IN_ACOS’ not handled in switch [-Wswitch]
../../gcc-4.9.2/gcc/asan.c:2012:11: warning: enumeration value ‘BUILT_IN_ACOSF’ not handled in switch [-Wswitch]
../../gcc-4.9.2/gcc/asan.c:2012:11: warning: enumeration value ‘BUILT_IN_ACOSH’ not handled in switch [-Wswitch]
../../gcc-4.9.2/gcc/asan.c:2012:11: warning: enumeration value ‘BUILT_IN_ACOSHF’ not handled in switch [-Wswitch]
../../gcc-4.9.2/gcc/asan.c:2012:11: warning: enumeration value ‘BUILT_IN_ACOSHL’ not handled in switch [-Wswitch]
Will they cause any problem? What are these?
the current gcc on cygwin is 5.4.0. You are wasting time to recompile 4.9.2 old version with 5.4.0 as compiler. The tutorial is of course obsolete – matzeri
Related
How can we get rid of such ruby warning messages reported when I execute a Homebrew command on MacOS ?
brew upgrade
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/FileUtils.rb:1267: warning: already initialized constant FileUtils::Entry_::S_IF_DOOR
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1267: warning: previous definition of S_IF_DOOR was here
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/FileUtils.rb:1540: warning: already initialized constant FileUtils::Entry_::DIRECTORY_TERM
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1540: warning: previous definition of DIRECTORY_TERM was here
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/FileUtils.rb:1542: warning: already initialized constant FileUtils::Entry_::SYSCASE
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1542: warning: previous definition of SYSCASE was here
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/FileUtils.rb:1595: warning: already initialized constant FileUtils::OPT_TABLE
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1595: warning: previous definition of OPT_TABLE was here
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/FileUtils.rb:1649: warning: already initialized constant FileUtils::LOW_METHODS
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1649: warning: previous definition of LOW_METHODS was here
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/FileUtils.rb:1656: warning: already initialized constant FileUtils::METHODS
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1656: warning: previous definition of METHODS was here
This is the open issue for the camel case warnings.
I tried to build FLTK 1.3.4-2 version on my mac. I followed the instruction, and successfully configure it.
But when I install it, it shows:
Compiling Fl_cocoa.mm...
In file included from Fl_cocoa.mm:55:
In file included from /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:128:
/System/Library/Frameworks/Foundation.framework/Headers/NSUUID.h:26:49: error: nullability specifier '_Nullable' cannot be applied to
non-pointer type 'uuid_t' (aka 'unsigned char [16]')
- (instancetype)initWithUUIDBytes:(const uuid_t _Nullable)bytes;
^
/System/Library/Frameworks/Foundation.framework/Headers/NSUUID.h:29:30: error: nullability specifier '_Nonnull' cannot be applied to
non-pointer type 'uuid_t' (aka 'unsigned char [16]')
- (void)getUUIDBytes:(uuid_t _Nonnull)uuid;
^
2 errors generated.
make[1]: *** [Fl_cocoa.o] Error 1
make: *** [install] Error 1
Does anyone know how to solve this problem?
It seems you build system is a bit of mix'n'match and through that you have found a compiler bug.
The error message indicates that the compiler is not recognising that an array type (uuid_t) when used as a function/method parameter type becomes a pointer type (as C-style arrays are passed by reference not by value) before it checks the validity of _Nullable/_Nonnull – so it throws the error as _Nullable/_Nonnull are not applicable to array types.
However not only isn't this your code, it is system code which is causing the error, which is surprising. Which is where the mix'n'match comes in...
Prior to the macOS10.13 SDK the two methods causing the error, initWithUUIDBytes: and getUUIDBytes:, were not annotated with nullability attributes. By default Xcode 8.1 uses the macOS10.12 SDK and your code should compile with that arrangement – the included header, NSUUID.h, will not contain the nullability attributes.
If you wrote your own code with array typed parameters and specified nullability then Xcode 8.1's compiler would produce an error – the bug is in (at least) that compiler. But this isn't your code...
Xcode 9.4.1 (lastest 9) by default uses macOS10.13SDK and again your code would compiler – the included header will contain the nullability attributes and Xcode 9.4.1's compiler will not produce an error as the bug has been fixed.
So at best guess either you are using Xcode 8.1 but with the macOS10.13+ SDK intentionally installed, or you've managed to install the macOS10.13+ SDK headers and you are using a version of gcc which has the bug, or you've got multiple versions of Xcode installed and the command line tools are not for Xcode 8.1 (How to switch between multiple Command Line Tools installations in Mac OS X (without installing XCode) may help), or some other scenario where you've got mismatched compilers and installed SDKs – nobody else but you can know what is actually installed on your system; the header file path is a system location so the header causing the issue isn't a copy in the FLTK source folder.
HTH
[BTW your gcc comes from 2007, if you are building with it you should probably update to something newer.]
I am getting a pair of warnings with version 2.22 of glibc:
In file included from /net/module/sw/glibc/2.22/include/pthread.h:23:0,
from foo.h:48,
from foo.c:23:
/net/module/sw/glibc/2.22/include/sched.h:74:57: warning: ‘struct timespec’ declared inside parameter list
extern int sched_rr_get_interval (__pid_t __pid, struct timespec *__t) __THROW;
^
/net/module/sw/glibc/2.22/include/sched.h:74:57: warning: its scope is only this definition or declaration, which is probably not what you want
In file included from foo.h:48:0,
from foo.c:23:
/net/module/sw/glibc/2.22/include/pthread.h:1002:21: warning: ‘struct timespec’ declared inside parameter list
const struct timespec *__restrict __abstime)
^
And:
In file included from /net/module/sw/glibc/2.22/include/sys/param.h:26:0,
from foo.h:51,
from foo.c:23:
/net/module/sw/glibc/2.22/include/limits.h:123:3: warning: #include_next is a GCC extension
# include_next <limits.h>
^
I am using GCC 5.3.0 with this version of glibc.
Since these warnings are referencing an external library I do not control, can I safely ignore these warnings if my application otherwise appears to pass tests?
My concern is that these warnings (particularly those related to pthread) may indicate the introduction of subtle bugs that I do not have tests to catch.
Yes, these warnings should be harmless, but the struct timespec warning is certainly odd. Usually, they would be masked by GCC's warning suppression for system headers.
I am learning writing Linux Kernel Modules and following the book Linux Device Drivers. which instructs building and configure a kernel of 2.6.x . I am using kernel version 2.6.10. I followed the steps on thegeekstuff.com/compile-linux-kernel
i.e. I after untarring in the /usr/src directory, I did
$ make menuconfig #this opened up a gui
then I saved the config without making any changes, in the hope to enforce default configuration and then
$ make.
when I did make, it gave me this error and the warning’
include/asm/mpspec_def.h:78:2: warning: ‘packed’ attribute ignored for field
of type ‘unsigned char[6]’ [-Wattributes]
arch/i386/kernel/process.c: In function ‘show_regs’:
arch/i386/kernel/process.c:259:2: warning: pointer targets in passing argument 2 of ‘show_trace’ differ in signedness [-Wpointer-sign]
include/asm/processor.h:499:6: note: expected ‘long unsigned int *’ but argument is of type ‘long int *
arch/i386/kernel/process.c: Assembler messages:
arch/i386/kernel/process.c:384: Error: operand type mismatch for mov'
arch/i386/kernel/process.c:385: Error: operand type mismatch formov'
arch/i386/kernel/process.c:461: Error: operand type mismatch for `mov'
include/linux/elfcore.h:92: Error: operand type mismatch for mov'
include/linux/elfcore.h:92: Error: operand type mismatch formov'
arch/i386/kernel/process.c:583: Error: operand type mismatch for mov'
arch/i386/kernel/process.c:584: Error: operand type mismatch formov'
arch/i386/kernel/process.c:591: Error: operand type mismatch for mov'
arch/i386/kernel/process.c:592: Error: operand type mismatch formov'
make1: [arch/i386/kernel/process.o] Error 1
make: [arch/i386/kernel] Error 2
I have not written professional kernel code before so I am not sure if I should make any changes in the code. Can anybody help me with why this error occurred and how it can be removed. I used the default kernel config. prior to calling make using make menu-config.
The error in the process.c is in savesegment(fs,p->thread.fs); (all instances of the error are from the same function)
Thanks
It is not clear from your question that what are the exact steps you did.
This error may be due to some issues in configuration.
Please try the following steps and see if it solves the problem:
> make defconfig #Creates a default config based on your machine architecture
> make
I used a kernel version who version was closer to my native kernel version ~ 3.11.1. and used make oldconfig instead. This was easier than figuring out each configuration setting for my architecture.
I am trying to build rtmpdump and librtmp on mac, however I cannot for the life of me work out why it isn't working. I am using my own built openssl:
$ openssl version
OpenSSL 1.1.0-pre3 (alpha) 15 Feb 2016
I have set the flags correctly (I think), but yet when I try and compile I get this:
$ make INC=-I/usr/local/include
gcc -Wall -I/usr/local/include -DRTMPDUMP_VERSION=\"v2.4\" -DUSE_OPENSSL -O2 -fPIC -c -o rtmp.o rtmp.c
In file included from rtmp.c:152:
./handshake.h:120:12: error: variable has incomplete type 'HMAC_CTX' (aka 'struct hmac_ctx_st')
HMAC_CTX ctx;
^
/usr/local/include/openssl/ossl_typ.h:145:16: note: forward declaration of 'struct hmac_ctx_st'
typedef struct hmac_ctx_st HMAC_CTX;
^
In file included from rtmp.c:152:
./handshake.h:125:3: warning: implicit declaration of function 'HMAC_CTX_init' is invalid in C99 [-Wimplicit-function-declaration]
HMAC_setup(ctx, secretKey, 128);
^
./handshake.h:72:35: note: expanded from macro 'HMAC_setup'
#define HMAC_setup(ctx, key, len) HMAC_CTX_init(&ctx); HMAC_Init_ex(&ctx, key, len, EVP_sha256(), 0)
^
./handshake.h:127:3: warning: implicit declaration of function 'HMAC_CTX_cleanup' is invalid in C99 [-Wimplicit-function-declaration]
HMAC_finish(ctx, digest, digestLen);
^
./handshake.h:74:67: note: expanded from macro 'HMAC_finish'
#define HMAC_finish(ctx, dig, dlen) HMAC_Final(&ctx, dig, &dlen); HMAC_CTX_cleanup(&ctx)
^
./handshake.h:269:12: error: variable has incomplete type 'HMAC_CTX' (aka 'struct hmac_ctx_st')
HMAC_CTX ctx;
^
/usr/local/include/openssl/ossl_typ.h:145:16: note: forward declaration of 'struct hmac_ctx_st'
typedef struct hmac_ctx_st HMAC_CTX;
^
rtmp.c:192:13: warning: comparison of constant 18446744073709551597 with expression of type 'uint32_t' (aka 'unsigned int') is always false [-Wtautological-constant-out-of-range-compare]
if (nSize > SIZE_MAX - RTMP_MAX_HEADER_SIZE)
~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 warnings and 2 errors generated.
make[1]: *** [rtmp.o] Error 1
make: *** [librtmp/librtmp.a] Error 2
It looks like it might be a compatibility issue with the version of OpenSSL I'm using. Does anyone know how to fix this kind of issue, or any changes to OpenSSL that might be responsible?
OpenSSL 1.1.0-pre3 (alpha) 15 Feb 2016...
Does anyone know how to fix this kind of issue, or any changes to OpenSSL that might be responsible?
Broadly speaking, there appears to be two high level changes in OpenSSL 1.1.x that caused most of the problems. First was the changes to the build system. Second was the firmer posture with respect to private APIs. I think you're seeing an artifact of the second, the private APIs.
Generally speaking, 1.1.0-pre3 and 1.1.0-pre4 have a number of problems and mostly can't achieve a successful make test. The issues include configuration and build issues for 32-bit OS X PowerMac, 64-bit OS X PowerMac, 32-bit OS X, 64-bit OS X, 32-bit ARM, 64-bit ARM, OpenBSD 5.7, NetBSD 7.0, Cygwin, CentOS 5, CentOS 7 and i686. So many so that I've filed about 25 bugs in preparation for the upcoming Beta-1 scheduled to arrive Monday, 14 MAR 2016.
You should probably avoid 1.1.0-pre-N at the moment because its so unstable. You should be OK under x86_64 Linux, but anything else is a crap shoot at the moment. You should be able to pick it up again around Beta-2.
You will probably have better luck with the tip of Master after commits from Friday, 11 MAR 2016. That would be roughly commits 0d4d5ab and 4c1cf7e. You can get the latest with:
git clone git://git.openssl.org/openssl.git
Or, use 1.0.2 stable releases.