I've been trying to compile wxWidgets for a while now, I've been using TDM-GCC and have been following the guide here with no such luck. The last few lines of my mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=release MONOLITHIC=1 is
../../src/msw/thread.cpp: In member function 'void wxThread::Exit(wxThread::Exit
Code)':
../../src/msw/thread.cpp:1165:28: error: cast from 'wxThread::ExitCode {aka void
*}' to 'unsigned int' loses precision [-fpermissive]
_endthreadex((unsigned)status);
makefile.gcc:4957: recipe for target 'gcc_mswudll\monodll_thread.o' failed
mingw32-make: *** [gcc_mswudll\monodll_thread.o] Error 1
Anyone got any ideas? Please help, I'm truly baffled.
With the help of #ravenspoint, and some googling, I found this, which mentioned passing the variable CXXFLAGS to pass arguments to g++ (and for gcc, use CFLAGS), then from #ravenspoint's answer I added CXXFLAGS+=-fpermissive to my mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=release MONOLITHIC=1, to pass -fpermissive to g++.
{aka void*} to unsigned int loses precision [-fpermissive]
That occurs when it expects 32 bit and gets a 64 bit, usually a problem in compiling code meant to be 32 bit in the TDM default -m64 bit mode.
For void* to lose precision, it must be a 64 bit variable, and unsigned int must be 32.
If you downgrade the variable by disabling the warning and run it on 64 bit machine, you could get a pointer error crash while running program.
Related
I have an error that I looked around the internet quite a bit yet I have yet to find a real solution to this problem. Here is the error message I get from my computer (Win 7):
POLINK: warning: /SECTION:.bss ignored; section is missing.
With this error, obviously comes some code. So what I am trying to do with the code is see what happens wham you mix signed and unsigned variables in the same calculation. I am sure this error shows up in other situations as well, but I haven't bothered to do too much about it. Anyways, here's the code:
program example;
#include ("stdlib.hhf")
static
unsigned: uns16;
dummy:byte;
begin example;
stdout.put ("Enter an int between 32 768 and 65
525");
stdin.getu16();
mov (ax, unsigned);
stdout.put (
"You entered",
unsigned,
". If this were a signed int, it would be: "
);
stdout.puti16 (unsigned);
stdout.newln();
end example;
Any help would be appreciated as to where this problem originates so anything would be appreciated.
Thank you
Firstly this is not an error message it is a warning.
As evident from POLINK: warning: /SECTION:.bss ignored; section is missing.
The linker called POLINK complains that the BSS section is missing, because in the assembly your HLA code snippet generates it is.
In order to make it go away, you can change HLA to use another linker that doesn't generate the warning message or you can add HLA code which populates the BSS with a dummy or placeholder variable.
The code to add would be
storage
dummy:byte;
before the begin example line.
Reference
- POLINK: warning: /SECTION:.bss ignored; section is missing. from MASM forums
I'm trying to compile some c code with g++ (yes, on purpose). I'm getting errors like (for example):
error: invalid conversion from 'void*' to 'unsigned char*' [-fpermissive]
adding -fpermissive to the compilation options gets me:
error: invalid conversion from 'void*' to 'unsigned char*' [-Werror=permissive]
which seems to be a error because of -Werror, however adding -Wno-error=permissive -Wno-permissive results in:
error: -Werror=permissive: no option -Wpermissive
error: unrecognized command line option "-Wno-permissive" [-Werror]
How do I disable warnings (globaly) for conversions from void* to other pointer types?
You cannot "disable warnings for conversions from void* to other pointer types" because this is not a warning - it is a syntax error.
What's happening here is that you are using -fpermissive which downgrades some errors - including this one - to warnings, and therefore allows you to compile some non-conforming code (obviously many types of syntax errors, such as missing braces, cannot be downgraded to warnings since the compiler cannot know how to fix them to turn them into understandable code).
Then, you are also using -Werror which upgrades all warnings to errors, including the "warnings" that -fpermissive has turned your error into.
-Wno-error is used only to negate -Werror, i.e. it causes -Werror to treat all warnings as errors except the warnings specified with -Wno-error, which remain as warnings. As the -W flag suggests, both these flags work with warnings, so they can't do anything with this particular issue, since what you have here is an error. There is no "warning" for this kind of invalid conversion that you can switch off and on with -Werror because it's not a real warning - it's an error that -fpermissive is merely causing to be treated as a warning.
You can compile your non-comforming code, in this case, by using -fpermissive and not using -Werror. This will still give you a warning, but like all warnings, it won't prevent successful compilation. If you are deliberately trying to compile non-conforming code, then using -Werror makes no sense, because you know your code contains errors and will therefore result in warnings, even with -fpermissive, so specifying -Werror is equivalent to saying "please do not compile my non-conforming code, even though I've just asked you to."
The furthest you can go to get g++ to suppress warnings is to use -fsyntax-only which will check for syntax errors and nothing else, but since what you have here is a syntax error, that won't help you, and the best you can do is have that turned into a warning by -fpermissive.
How do I disable warnings (globaly) for conversions from void* to
other pointer types?
Well it might require direct interaction with compiler's code. This is probably not what you want. You want to fix your code. First, these are not warnings but errors. You need to cast void* as you can not convert a void* to anything without casting it first (it is possible in C however which is less type safe as C++ is).
For example you would need to do
void* buffer = operator new(100);
unsigned char* etherhead = static_cast<unsigned char*>(buffer);
^
cast
If you want a dynamically allocated buffer of 100 unsigned char then you are better off doing this
unsigned char* p = new unsigned char[100];
and avoiding the cast.
void pointers
I am using CodeBlocks 10.05 with Cygwin 1.7 to compile some C++ codes. The operating system is WinXP SP3. The compiler used is g++ 4.5.3.
When I build the following program:
#include <stdio.h>
#include <stdlib.h>
using namespace std;
int main()
{
unsigned long long a = 12345678901234;
printf("%u\n",a);
return 0;
}
it outputs the following in the build log:
C:\Documents and Settings\Zhi Ping\Desktop\UVa\143\main.cpp||In function ‘int main()’:|
C:\Documents and Settings\Zhi Ping\Desktop\UVa\143\main.cpp|9|warning: format ‘%u’ expects type ‘unsigned int’, but argument 2 has type ‘long long unsigned int’|
C:\Documents and Settings\Zhi Ping\Desktop\UVa\143\main.cpp|9|warning: format ‘%u’ expects type ‘unsigned int’, but argument 2 has type ‘long long unsigned int’|
||=== Build finished: 0 errors, 2 warnings ===|
I do not know why CodeBlocks prints the ‘ etc. symbols. Is there a way for CodeBlocks to properly display the characters?
Cygwin defaults to the UTF-8 encoding, whereas it looks like CodeBlocks assumes that output is in CP1252. Furthermore, since Cygwin tells it that UTF-8 is available, gcc uses separate left and right versions of quote characters instead of the usual ASCII ones. The result is what you're seeing. There are two ways to tackle this: either tell CodeBlocks to use UTF-8, or tell gcc to stick to ASCII by setting LANG=C. I don't know how to do either of these in CodeBlocks though.
Add the following Environment Variable to your computer:
LANG=C
In Windows 7, you can add it by going to Computer > Properties > Advanced System Settings > Environment Variables, then "New...". The menus should be similar in Windows XP.
I hope it's ok to answer an old question. This happened to me today as well, and it took me a while to fix it.
I installed the CodeSourcery g++ toolchain and tried to compile a simple hello world program:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World" << endl;
return 0;
}
And got a lot of errors from the linker
$ arm-none-eabi-g++ helloworld.cpp -o helloworld.exe
bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000008018
lib/libc.a(lib_a-abort.o): In function `abort':
abort.c:(.text.abort+0x10): undefined reference to `_exit'
lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text._fstat_r+0x1c): undefined reference to `_fstat'
lib/libc.a(lib_a-openr.o): In function `_open_r':
openr.c:(.text._open_r+0x20): undefined reference to `_open'
lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0x18): undefined reference to `_sbrk'
lib/libc.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text._kill_r+0x1c): undefined reference to `_kill'
lib/libc.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text._getpid_r+0x4): undefined reference to `_getpid'
lib/libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x20): undefined reference to `_write'
lib/libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text._close_r+0x18): undefined reference to `_close'
lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text._isatty_r+0x18): undefined reference to `_isatty'
lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text._lseek_r+0x20): undefined reference to `_lseek'
lib/libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text._read_r+0x20): undefined reference to `_read'
collect2: ld returned 1 exit status
What library am I missing here?
The GCC toolchain is only half of what you need to create a working executable*. The other half is the runtime library. The runtime includes crt0.o, which contains the entry point (the code that calls main()), and generally a libc that contains the standard C functions (strcmp(), memcpy(), etc) as well as the system calls (open(), read(), and others). You need to find a source for these. If you're targeting an embedded Linux or BSD machine, you'll have to find out what libc your target is using. It's probably either GNU libc, BSD libc, newlib, or uclibc. You can get these and build them yourself, or they may be available already with your OS.
*unless you're building a freestanding binary, but this doesn't look to be what you're doing.
Basing on the cross compiler it appears that end target is bare metal. The default gcc libraries (OS dependent) will not work here. You can use the NewlibC or NewlibC-Nano. This generally will be shipped along with the cross compiler tool chain.
Look for lib folder which has precompiled NewlibC.
Once that is done,
This statement might help you to an extent.
arm-none-eabi-gcc --specs=rdimon.specs \
-Wl,--start-group -lgcc -lc -lc -lm -lrdimon -Wl,--end-group $(OTHER_OPTIONS)
Don't forget to provide the path of looking the libraries -L(path).
I had this same problem.
It turns out there are a handful of options you can send to the linker to make it start working, but the one that had the least splash damage in my code base was
-nostartfiles
try to apply a patch and compile received warning message:
<some_file>: In function '-[XXXXX saveAndCreate:]':
<some_file>:262: warning: 'NSString' may not respond to '-stringByReplacingOccurrencesOfString:withString:'
<some_file>:262: warning: (Messages without a matching method signature
<some_file>:262: warning: will be assumed to return 'id' and accept
<some_file>:262: warning: '...' as arguments.)
distcc[6493] ERROR: compile (null) on localhost failed
which is complaining about this code,
[clientHost findAvailableIn:
[clientHost defaultVMPath]
baseName:
[displayName stringByAppendingPathExtension:PL_BUNDLE_EXTENSION]
nameFormat:[[displayName
stringByReplacingOccurrencesOfString:#"%"
withString:#"%%"]
stringByAppendingString:#" %u.xxxx"]
startIndex:2
contextInfo:contextInfo];
and here is part of the compile command:
lin32/gcc-5363-1/bin/i686-apple-darwin8-gcc -mmacosx-version-min=10.4 -arch i386 -march=pentium-m -mtune=prescott -Werror -Wall -Wno-trigraphs -Wreturn-type -Wunused-variable -pipe -O2 -g3 -gfull -Wno-pointer-sign -x objective-c -fobjc-exceptions -fpascal-strings -fmessage-length=0
googled the warning and tried the method here , but still got warning message alike.
i am ignorant in Mac development, spare me if this is something obvious (and i donnot know if the information provide above is surfficent, let me know what else needed to provide). thanx.
edit:
1) extend the code block.
2) correct the warning message.
The warning is referencing a different line the one you cited. The message you use is called stringByReplacingOccurrencesOfString:withString: which is fine on NSString. However the method replaceOccurrencesOfString:withString attempts to change the receiver. NSString is immutable and can therefore not be changed. If you want to use that method send it to a NSMutableString object.
Are you importing <Foundation/Foundation.h>? What is very surprising is that you would receive this warning, but no warning on -stringByAppendingPathExtension. Is this really the only warning you're receiving?
I recommend breaking up the code to create some temporary variables. You're doing so many nested method calls, it makes it very hard to be certain where your errors are. The compiler will optimize out most temporary variables, so there's no reason to avoid them when it makes the code clearer.