gcc 4.0 (Full Version)

All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum



Message

jumphigh -> gcc 4.0 (Nov. 9, '05, 11:44:14 AM)

Hi forum,

I'm trying to build the gcc-4.0.2 tarball on Interix. Things went fine after a minor change in configure, but now the build exits with error about a "_chkstk.o". Can't find a file with a similiar name nor source for it. I even can't figure out which Makefile is currently used, not to mention the line of the rule.
I believe there was already a post about "_chkstk.o" in this forum. But search can't help. Does anyone remember it?

And a second question: When inspecting one of your executables or the ones shipped with SfU, the file command tells me something like "Interix-CUI DOS executable (EXE)". But when building my apps I only get "Interix-CUI". What are the gcc settings to get a command line marked exe (I guess, that's what it is for.)?

Any help welcome,
Andreas



Rodney -> RE: gcc 4.0 (Nov. 10, '05, 3:43:27 AM)

> I'm trying to build the gcc-4.0.2 tarball on Interix.

Member wysoft is trying gcc 3.4.4 in another thread. I guess this is gcc week now [:)]

> But search can't help. Does anyone remember it?

I don't recall. But I suggest the same to everyone asking about building gcc:
look at the notes and diffs that come on the SFU CD.
You'll want to try and use this data because you will need to make changes to the code.

> And a second question: When inspecting one of your executables or the ones shipped with SfU, the file command tells me something like
> "Interix-CUI DOS executable (EXE)". But when building my apps I only get "Interix-CUI". What are the gcc settings to get a command line
> marked exe (I guess, that's what it is for.)?

All it means is that one was linked using MSVC and other was linked using gcc's ld.
This is in the "don't sweat it" category".



jumphigh -> RE: gcc 4.0 (Nov. 11, '05, 6:19:36 AM)

Hi Rodney!

Oh, it was my mistake. After a small fix in the configure script (-L/usr/local/ssl/lib stopped the first test for the installed gcc???), I stupidly startet the build with "make" instead of "gmake".
Now I extracted the source tar ball again and made a clean restart. What should I say: It runs through the process and made me a new gcc-4.0.2 without errors! It seems that the GNU guys included all diffs needed for Interix3. But I got a show stopper when building libstdc++-v3 because libffi is not ported to Interix. I have to check this out, maybe now I need the diffs from the SfU shipped gcc-3.3.

So my advice to you: You should build a new gcc4 for us, if we can't fix the new lib we can use the old one from SfU. I would do it for us, but I never build a installer pkg, so I don't know what to do at the moment.
quote:

ORIGINAL: Rodney
> And a second question: When inspecting one of your executables or the ones shipped with SfU, the file command tells me something like
> "Interix-CUI DOS executable (EXE)". But when building my apps I only get "Interix-CUI". What are the gcc settings to get a command line
> marked exe (I guess, that's what it is for.)?

All it means is that one was linked using MSVC and other was linked using gcc's ld.
This is in the "don't sweat it" category".


I know that link.exe from MSVC kann produce a PE marked for POSIX. So I have a new question: It seems that the object format of gcc and cl is the same (COFF?), so it doesn't matter if you link with link.exe or ld? If I'm right than also a file lib*.a should be the same as a library_xy.lib for Win32?
When doing a POSIX link with link.exe which basic libs are used? I would say msvcrt or similiar isn't suitable for a POSIX-PE, so do I have to specify libc and all other shared libs from our SfU directory tree? And is link.exe capable of building shared libs for Interix?

I ask that because I believe you're building the apps with the MS tools. I checked gzip what I have from your site and "file" told me the additional "DOS executable". And am I right that "file" reads POSIX in booth cases (linked with ld or link.exe) from the PE and only translate it into Interix, because Interix is the only POSIX subsystem available for WinNT?

Hope, these are not too much questions,
Andreas

PS: What are *.lo and *.la files? And why checked "configure" the installed gcc-3.3 as not capable of building shared libs?



jumphigh -> RE: gcc 4.0 (Nov. 11, '05, 7:04:33 AM)

It seems GCC-4.0.2 is ported without to manually change important things.
I couldn't compile Libffi, libjava (depends on libffi), and boehm-gc (a garbage collector), but I believe that you don't need them for C/C++ development. I killed these targets in the Makefile, and now I believe I could do a "gmake install". But I'm affraid of corrupting my SfU installation. ;-(

Andreas



jumphigh -> RE: gcc 4.0 (Nov. 11, '05, 10:34:00 AM)

OK, I tried an install, and after copying ld and as from the SfU gcc3.3, the excutables seems to work.
But problems still remain:

1. Compiling the standard "Hello World!" program, I got this from gcc:
quote:


test.c: In function 'main':
test.c:5: warning: incompatible implicit declaration of built-in function 'printf'

But the program runs!

2. Compiling a C++ test app, I got no errors or warnings from g++/gcc, also --verbose is ok. But I can't run the executable, although "file" or "depends" from Win32 say it's a valid POSIX-PE. Is there a way to figure out what's wrong, maybe a tool like "depends" that tells me if something is wrong with the shared libs? But also a static build doesn't work.

Beside there are some strange things:

3. A normal C program compiled with "-shared" crashes with a segmentation fault, compiled without "-shared" (the doc says that shared is use as default?) it works, but has a different size to the first one.

4. A C++ test gives the same size of the executable for "-static" or "-shared" option. Without booth, the result is a little smaller. But as already mentioned, all three apps don't run, even "truss" give me no hint.

Andreas



jumphigh -> RE: gcc 4.0 (Nov. 14, '05, 11:15:21 AM)

Here is another update, maybe someone have a clue:

Gcc 4.0.2 works fine for C sources, seems there are no problems so far.

The problem with C++ still remains. But I have a idea: Seems that the linker can't handle the mangled names, or libstc++ wasn't createt the right way, because the resulting excutable of my test programs have more PE sections than allowed. So the Win loader can't handle it.
There are too much sections named like ".text._xyz" (xyz stands for the encoded C++ names), so the linker don't merge them to one ".text" section.
Does someone knows how to instruct "gcc", "ld" or maybe "ar" (?) to use one name for all C++ code? I think that will solve the problem.

Regards,
Andreas

PS: Rodney, I hope you will read my post:
I see that you're building the apps with the MS tools. Do you know how to supress the warnings from link.exe that there are several ".drectve" sections in libc.a with different attributes (LNK 4078) and the CRT warning on libc.a (LNK 4210)? It seems that the first one is only a minor warning, the second one could be a problem, but the CRT section of libc.a is fortunately empty, so you can merge this section with ".text" without problems and get a additional LNK4078.
Have you ever managed to link a GCC compiled source with the MS linker "link.exe"? I always get a core dump, although the linker gives no warnings?



Rodney -> RE: gcc 4.0 (Nov. 14, '05, 2:50:03 PM)

> PS: Rodney, I hope you will read my post:

I am reading :-)
I build the apps with both MSVC/c89 and gcc depending what is needed.
I try to build binaries that will be static with MSVC because the resulting code will be a bit faster
and the binary shouldn't be as likely to trigger the DEP problem. For shared programs and libraries
I build with gcc because this is the only way.

I've actually kept away from the compiler internals of gcc et al because until a couple of
years ago there was someone specifically assigned at MS to do this work. And this work can consume
a large amount of time for a long period of time. That fellow has since moved to a new project.
I don't know who (if anyone) is specifically assigned to it at MS right now.

> Have you ever managed to link a GCC compiled source with the MS linker "link.exe"?

I have via the c89/cc scripts. I've had the *.o files generated by gcc and then
linked with c89. There are a couple of unusual points that appear sometimes. Member
markfunk worked out one of them (in a configuration file) and that has been rolled
into a patch/package available in the warehouse. But that was for finding a particular function.

The diff's that are available for gcc 3.3 may be helpful for you to solve the problem.
Everyone who has downloaded SFU 3.5 has a copy of those diff's. My best suggestion is to read
through those diff's.



jumphigh -> RE: gcc 4.0 (Nov. 14, '05, 3:59:29 PM)

I MADE IT!

They used "-ffunction_section" for building the new libstdc++, so every function gets its own section. The result was more than 500 sections in the PE, and Windows say "ooops". I cleared these flags, now everything works fine. I also removed /opt/gcc.3.3/bin from the path, to be sure that only gcc4 is used.

After all, I must say it was quite simple to port GCC-4.0.2, although some problems remain: I got no shared libs (maybe they can be built with the MS tools), Java isn't complete because of the missing libjava (depends on libffi). The fact is, that libffi isn't ported to Interix, but I had no time to look what libffi is about. Also the Boehm garbace collector is missing, but who is using it?

Now I should lern how to build a package for your site, if you don't miss the shared libs (But linking without "-static" works, maybe the old ones from SfU are enough?). Or you build gcc-4.0.2 on your own, because unpacking the tarball and configure/gmake is nearly all to do.

My changes:
1. The original configure scripts don't run, because they crash when trying to test a old gcc as build host. Seems that the scripts don't like "-L/usr/local/ssl/lib" in LD_FLAGS, so I set a new LD_FLAGS without this path.
2. One generated script has a missing "#! /usr/bin/sh".
3. Clear all targets related to libffi, libjava and boehm-gc from the main Makefile.
4. Clear out SECTION_FLAGS from every Makefile in i586-pc-interix3/libstdc++-v3. This stops the generation of to much PE sections.
5. Use gmake instead of make!
6. After "gmake install" copy ld and as from the old gcc.3.3 directory to the new "/usr/local/libexec/gcc/i586-pc-interix3/4.0.2".
7. Clear gcc.3.3 out of the PATH inside /etc/csh.login and /etc/profile. But don't delete /opt/gcc.3.3, because after I made that (rename), nothing worked in Interix. Seems that some libs (ld.so) should be copied over to /usr/lib.
8. Run catman to build the new help files.

That'a all I remember at the moment.

Regards,
Andreas



Rodney -> RE: gcc 4.0 (Nov. 14, '05, 5:35:25 PM)

WOW! [:D]
Congratulations!

You are now crowned as our gcc build expert [:)]

I'm going busy crazy today (off-line) so I will respond more later.



Rodney -> RE: gcc 4.0 (Nov. 17, '05, 3:47:24 AM)

Andreas/jumphigh has packaged up his build of gcc version 4.0.2.
I've placed it in the beta directory for people to try if they would like.
(I haven't had a chance to try it myself yet).

It's at ftp://ftp.interopsystems.com/pkgs/beta/gcc-4.0.2.i1-bin.tgz
Here's a useful snip from the e-mail Andreas sent me:
quote:

Give it a try, I also included a small README in the package description. I think you have more possibilities than me, so I would like to see if it works on a clean SfU installation without the gcc.3.3. I tested it on my installation with renamed /opt/gcc.3.3 and it worked fine (I also included some shared libs from this gcc3.3). Please check out if libc is installed without gcc.3.3. If so we could make a complete replacement package for developers! If not we have to ask if libc is freely distributable in a package.



jumphigh -> RE: gcc 4.0 (Nov. 18, '05, 4:01:58 PM)

There are 2 "final" packages. I hope Rodney will put them into the beta directory.

gcc3_sharedlibs-1.0.0-bin.tgz
gcc-4.0.2.i2-bin.tgz

I made a clean install of SfU without the GNU SDK. I got only the shared libs from GCC 3.3 into the /opt/gcc.3.3 folder. So I made the first package to place them directly into /usr/lib. Now I can savely remove /opt/gcc.3.3 (sometimes the loader locks ld.so.1, so you have to stop POSIX to rm that folder).
The second package is GCC 4.0.2. C/C++ seems full functional, Fortran, Objc and Treelang as well (no tests). The Java compiler frontends are also included, but I couldn't build libjava so far. You can read more in the package description.

Andreas



Rodney -> RE: gcc 4.0 (Nov. 18, '05, 5:00:28 PM)

I hadn't put gcc3_sharedlibs-1.0.0-bin.tgz anywhere.
You're e-mail only had gcc-4.0.2.i2-bin.tgz mentioned.
I'll take a look for the other one.



jumphigh -> RE: gcc 4.0 (Nov. 19, '05, 3:16:29 PM)

Oh, I made a new upload yesterday. I splited the original i1 package into gcc3_sharedlibs and an new i2 GCC 4 package. Now I also have more experience with pkg_create, so both packages are a way better than the first one. I made some corrections in my little readme, too.
Please look inside your upload dir for

gcc3_sharedlibs-1.0.0-bin.tgz
gcc-4.0.2.i2-bin.tgz

and clear the original gcc-4.0.2.i1-bin.tgz from the beta directory.

As I told already I made a clean install of SfU without the "Interix GNU SDK" (also no Perl, you have the new version ;-) ), and used my two new packages without problems so far. It's fantastic, since I had no experience with porting open source software so far. But I have to thank the guys from GNU (although their automake/configure system is a lot of pain), because they support i586-pc-interix3, so I didn't need to look for the diffs inside the old gcc.3.3 sources from MS.

Andreas



jumphigh -> RE: gcc 4.0 (Nov. 24, '05, 12:27:30 PM)

Hello Rodney,

please update my packages! There's still the old i1 inside the beta directory, but I gave you new ones inside /upload.

Andreas



twhetten -> RE: gcc 4.0 (Nov. 28, '05, 3:22:29 PM)

When I try and build, I seem to always fail compiling "c-parse.c". Here's a snippet of the output at the point of failure. I'd be grateful for any help figuring out what's wrong.

Thanks!


--SNIP--

stage2/xgcc -Bstage2/ -B/usr/local/i586-pc-interix3/bin/ -c -D__INTERIX -D_ALL_SOURCE -g -O2 -DIN_GCC -W -Wall -Wwrit
e-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wno-error -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.0.2/gcc -I../../gcc-4.0.2/gcc/. -I../../gcc-4.0.2/gcc/../include -I.
./../gcc-4.0.2/gcc/../libcpp/include -D_ALL_SOURCE -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/include/
php ../../gcc-4.0.2/gcc/c-parse.c -o c-parse.o
c-parse.c:2218:12: error: #if with no expression
c-parse.c:2328:20: error: #if with no expression
c-parse.c: In function 'yyparse':
c-parse.c:2534: error: 'yystacksize' undeclared (first use in this function)
c-parse.c:2534: error: (Each undeclared identifier is reported only once
c-parse.c:2534: error: for each function it appears in.)
c-parse.c:2538: warning: ISO C90 forbids mixed declarations and code
c-parse.c:2580: error: '__SIZE_TYPE__' undeclared (first use in this function)
c-parse.c:2580: error: syntax error before 'yysize'
c-parse.c:2596: warning: left-hand operand of comma expression has no effect
c-parse.c:2596: error: 'yysize' undeclared (first use in this function)
c-parse.c:2596: warning: left-hand operand of comma expression has no effect
c-parse.c:2597: warning: left-hand operand of comma expression has no effect
c-parse.c:2597: warning: left-hand operand of comma expression has no effect
c-parse.c:2599: warning: left-hand operand of comma expression has no effect
c-parse.c:2599: warning: statement with no effect
c-parse.c:2684: error: syntax error before '<' token
c-parse.c:2695: error: syntax error before ')' token
c-parse.y:353: error: syntax error before ';' token
c-parse.y:354: warning: left-hand operand of comma expression has no effect
c-parse.y:354: warning: statement with no effect
c-parse.y:356: error: 'NULL' undeclared (first use in this function)
c-parse.y:365: warning: statement with no effect
c-parse.y:371: warning: left-hand operand of comma expression has no effect
c-parse.y:371: warning: assignment makes pointer from integer without a cast
c-parse.y:379: error: 'POP_DECLSPEC_STACK' undeclared (first use in this function)
c-parse.y:395: warning: empty body in an if-statement
c-parse.y:398: error: incompatible types in assignment
c-parse.y:408: error: 'YYERROR1' undeclared (first use in this function)
c-parse.y:411: warning: implicit declaration of function 'DECL_SOURCE_LOCATION'
c-parse.y:411: error: invalid lvalue in assignment
c-parse.y:424: error: invalid lvalue in assignment
...
In file included from c-parse.y:2963:
./gt-c-parse.h: At top level:
./gt-c-parse.h:30: error: syntax error before ',' token
./gt-c-parse.h:32: warning: missing initializer
./gt-c-parse.h:32: warning: (near initialization for 'gt_ggc_r_gt_c_parse_h[0].cb')
./gt-c-parse.h:37: error: 'gt_ggc_mx_tree_node' undeclared here (not in a function)
./gt-c-parse.h:39: error: 'gt_pch_nx_tree_node' undeclared here (not in a function)
./gt-c-parse.h:39: warning: missing initializer
./gt-c-parse.h:39: warning: (near initialization for 'gt_ggc_r_gt_c_parse_h[1].cb')

--END SNIP--



jumphigh -> RE: gcc 4.0 (Nov. 29, '05, 7:38:00 AM)

I think I had the same error. I can't remember exactly what I have done, but it helps a lot, if you update SfU with some tools from here. Seems that some files have content which is produced locally on your buildhost with some tools. If they are missing, or you have a incomaptible version, things went wrong during build.

Most important you should add some GNU tools (and update some of the shipped tools!): gmake, m4_gnu, bison, yacc, flex, texinfo, ...
Build is easy if you only ask for c, c++, objc, f95,treelang. I only added "LDFLAGS=-static" into ${SCRDIR}/config/mh_interix to get static compilers which don't rely on the old SfU shared libs. Of course there were some additional showstoppers but you should be able to solve it without affords!
Unfortunately you only get static runtime libs (Configure can't determine how to build shared libs, although I updated with libtool from here!), so you have to modify some of the generated Makefiles if you want shared libs for your package. I don't know if I used the right options (I figured it out from the CC wrapper for the MS build tools), but I checked it out with Filemon, what libs test apps will use and what size they have whether they were built with or witout the "-static" switch. My package works as expected. ;-)

Andreas



spahlinger -> gcc 4.0 problems with shared libs? (Nov. 30, '05, 7:35:50 AM)

I tried to compile the following program (x.f95) with gfortran:

print*,'x'
end

bash-3.00$ gfortran x.for
bash-3.00$ ./a.out
Fortran runtime error: End of record
bash-3.00$ gfortran -static x.for
bash-3.00$ ./a.out
x
bash-3.00$

That means x.for does not run when linking with shared libs (libgfortran.so ?)
With static libs all is as expected.

Can you reproduce this behaviour?



jumphigh -> RE: gcc 4.0 problems with shared libs? (Dec. 1, '05, 8:04:40 AM)

You're right!

Seems that the shared lib doesn't work. But it's not a real problem, you get static linked apps for fortran. I don't want to fix it, since configure/gmake didn't build shared libs, they are an additional benefit made by myself.

Now I have three "developer packages" as replacement for the old GCC 3.3:

gcc3_sharedlibs-1.0.0-bin.tgz
binutils-2.13.90.i1-bin.tgz
gcc-4.0.2.i3-bin.tgz

I splitted binutils and gcc, because I wanted to get the new Binutils 2.16.1. The build for these new utils works perfect, but ld won't link. So I took the old ones from the SfU package, added the new gas (as), mans and infos, libbfd/libopcodes and made a new package.
I also rebuild gcc with some new options twhetten suggested from the old gcc 3.3. The new package also has fixes for installing the info pages. I also removed the shared libgfortran as well as the language frontends for java and ada (since their libs don't work, too).

I will mail Rodney to put all packages into the beta directory.

Andreas



Rodney -> RE: gcc 4.0 problems with shared libs? (Dec. 1, '05, 2:02:20 PM)

I will get them up by the end of today.

Splitting the binutils off is the right way to go I think.



Matt -> Update - GCC 4.1.0 (Mar. 3, '06, 3:16:00 PM)

Recently, there has been a major update of the GCC:
http://gcc.gnu.org/gcc-4.1/changes.html

Are there any plans to incorporate this or perhaps future releases from 4.1.x branch to SUA?



Page: [1] 2   next >   >>



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.109