Hey I am just wondering if someone can tell if this compiling error has something to do with needing GCC4.0:
/boot/home/Desktop/nasm-2.03.01>make
gcc -c -g -O2 -W -Wall -pedantic -DHAVE_CONFIG_H -I. -I. -o nasm.o nasm.c
In file included from /boot/develop/headers/posix/limits.h:5,
from /boot/develop/tools/gnupro/lib/gcc-lib/i586-pc-haiku/2.95.3-haiku-080323/include/limits.h:117,
from /boot/develop/tools/gnupro/lib/gcc-lib/i586-pc-haiku/2.95.3-haiku-080323/include/syslimits.h:7,
from /boot/develop/tools/gnupro/lib/gcc-lib/i586-pc-haiku/2.95.3-haiku-080323/include/limits.h:11,
from /boot/develop/headers/posix/stdlib.h:11,
from /boot/home/Desktop/nasm-2.03.01/nasm.c:13:
/boot/home/Desktop/nasm-2.03.01/float.h:18: warning: comma at end of enumerator list
/boot/home/Desktop/nasm-2.03.01/float.h:20: parse error before uint8_t' In file included from /boot/home/Desktop/nasm-2.03.01/nasm.c:20: /boot/home/Desktop/nasm-2.03.01/nasm.h:78: warning: comma at end of enumerator list /boot/home/Desktop/nasm-2.03.01/nasm.h:180: warning: comma at end of enumerator list /boot/home/Desktop/nasm-2.03.01/nasm.h:191: warning: comma at end of enumerator list In file included from /boot/home/Desktop/nasm-2.03.01/preproc.h:12, from /boot/home/Desktop/nasm-2.03.01/nasm.c:25: /boot/home/Desktop/nasm-2.03.01/pptok.h:97: warning: comma at end of enumerator list /boot/home/Desktop/nasm-2.03.01/nasm.c:91: warning: comma at end of enumerator list /boot/home/Desktop/nasm-2.03.01/nasm.c: In functiondefine_macros_early’:
/boot/home/Desktop/nasm-2.03.01/nasm.c:232: warning: ANSI C does not support the `ll’ length modifier
make: *** [nasm.o] Error 1
/boot/home/Desktop/nasm-2.03.01/float.h:20: parse error before `uint8_t’
You need to check that header file - float.h and figure out why you’re getting a parse error around line 20.
This might be the cause or a clue:
/boot/home/Desktop/nasm-2.03.01/float.h:18: warning: comma at end of enumerator list
Newer compiler may work better with the code because it understands newer syntax better. You could use GCC 3.4, from Bebits, for C code ( .c ), but NOT for C++ ( .cc and cpp ).
No worries, I actually think it only relates to gcc3.4. I’m testing with gcc2.95 and it seems to find stdint.h without issues. So, seems like gcc3.4 does NOT link properly to the header directories - something to watch out for.
I haven’t tested this but your issue may relate to BEINCLUDES; /boot/home/config/include is not listed in there. You can check with:
env | grep BEINCLUDES
or
env | grep /boot/home/config/include
This may fix it but I haven’t tested:
export BEINCLUDES="$BEINCLUDES; /boot/home/config/include"
You’d either have to run that every time before compiling or put it into one of the startup scripts.
I don’t know why but BEINCLUDES uses ; ( semi-colon ) to seperate whereas other PATHS use : ( colon )
Yeah, I noticed that also. I did try adding it, but it didn’t seem to work. Since I was in a hurry at the moment, I ended up just copying the header I needed to the /boot/develop/headers/3rdparty location instead which worked just fine.
Perhaps it’s a bug of some kind - I’ll look into it again soon Let me know if you happen to test this yourself and it works fine (email me privately if you want).
Stuff like that should go into a UserSetupEnvironment script (I assume that’s what you meant by “startup scripts”.
IIRC, mmu_man told me at the time I ran into it that “/boot/home/config/include” was supposed to be in the BEINCLUDES already - so maybe that is something we should report on Trac.
Does those gcc’s even understand BEINCLUDES and use it?
I suspect, but don’t know, that they have no clue about BEINCLUDES. When I crosscompile Firefox with gcc4.12 I flattened the include tree for those includes that where included with <stdint.h> instead of <posix/stdint.h>. So at least the crosscompiler does not handle it.
GCC wouldn’t know about BEINCLUDES unless the person that compiled GCC changed the code & made it aware. ( my guess - because gcc3.4 wasn’t aware of headers/posix folder even though it is listed in BEINCLUDES ).
gcc2.95 knows about /boot/develop/headers/posix but it could be a path or link and not because of BEINCLUDES. It’s unlikely that adding /boot/home/config/include to BEINCLUDES will make gcc aware of this directory but nothing lost in trying it out.
You’re cross compiling GCC4 Firefox? Right?
I’m having trouble with cross compiling GNU’s hello with GCC4. I get a symbol error for __fpending when I run the program on GCC4 Haiku. Can you cross compile then run GCC4 hello on GCC4 Haiku & let me know if it works for you?
Here are my build instructions, these I was going to write for Crosscompiling Firefox over at Bebits wiki anyways.
First, a working cross-compiler setup: (Reusing the one we built for Haiku crosscompiling). http://hem.bredband.net/b143824/setup_compiler.sh
Only needed to be done once. Read the script and modify as appropriate first. ./setup_compiler.sh
Second, setup environment for crosscompiling: export PATH=/home/frho/haiku/haiku-compiler/bin:$PATH
Third, run configure for crosscompiling: ./configure --prefix /home/frho/projects/hello/ --host i586-pc-haiku
Build and install make
make install
And then you need to include it in your Haiku build. Edit build/jam/UserBuildConfig to include: CopyDirectoryToHaikuImage home hello : /home/frho/projects/hello/bin : : -L ;
If i recall correctly the -L was to follow symlinks or something.
Thanks for the info & trying out Hello World compile, Fredrick.
__fpending is listed in stdio_ext.h, which I believe is part of glibc.
I use grep to find symbols in libs - it works well and lets me know which libs to link in ( when programs don’t compile right, ie: link errors ). I don’t believe any libs had __fpending ( or fpending ) when I grepped them. I’m fairly sure that this symbol is not in any of the libs.
I think gcc2.95 compiled and ran the Hello program fine. No fpending with gcc2.95 ( & for gcc3.4 either? ).
No worries, so long as I avoid programs that require stdio_ext.h I should be fine with gcc4.x compiling for Haiku - I think. Bye,
While __fpending() is located in the stdio_ext.h in the haiku repo, i found out after submitting a stdio_ext.h patch that it isn’t actually implemented in haiku’s glibc.
In fact, the only methods from stdio_ext.h that are actually implemented are __fsetlocking() and a weak alias for _flushlbf()
So, until someone implements that, software relying on it won’t be compiling.
stdio_ext.h only represents extensions to stdio, so posix compliant software shouldn’t necessarily rely on these - and should utilize other methods when they’re missing.
Although I haven’t tried 3.4 due to a sever error for the download link on bebits(the sever disconnects every 10 secs, flashgot seems to be able to handle it even if it is going so very slow), I still think it won’t work as gcc’s website says c99 is only really supported in gcc4.0 and a double set of commas as in line 18 of float.h is a sign of c99 code.
I can’t really say about c99 but when using gcc3.4; configure reports:
checking if gcc accepts -std=c99… yes
For gcc2.95, configure says accepts std=c99… no.
There is a test directory but the Makefiles don’t compile the tests. I believe NASM will work fine but without doing tests or checks I can’t say for sure. ( I had trouble getting the test programs to work right but spent a few minutes only ).
PS This is just one example of why going to GCC4.x would be a good thing - make it easier to compile programs. ( Firefox 3 requires 4.x & I believe WebKit too, etc. )
GCC 4.3.1 - latest, June 2008
GCC 3.4.3 - released Nov 2004
GCC 2.95.3 - released March 2001
you’re right Urias, should be: #include <stdint.h>
but when I compile it never finds stdint.h when I put in either: #include <stdint.h> or <posix/stdint.h>
Neither of these work.
I must not have my development set up right ( not sure what I’m missing; maybe environment variables? ). That’s why I like using the full path because it works for sure but the way you say to do it is the proper and standard method - the right way.
Also, I have to set CFLAGS="-I/boot/develop/headers/posix" for configure to find stdint.h - that’s how I know something is not right. I notice BEINCLUDES has /boot/develop/headers/posix. What am I missing?
Yeah, I’m not sure what’s wrong there - I ran into a similar problem the other day trying to get headers in /boot/home/config/include to work.
I may take a look at it myself if I get a chance. Even better would be to get someone at HaikuPorts to take a stab at it, as they’re pretty good at getting stuff updated and producing patches to submit back upstream.
Let me know if you happen to test this yourself and it works fine (email me privately if you want).
- I ran into a similar problem the other day trying to get headers in /boot/home/config/include to work.