1. Compile problem with 1943
- Posted by georgeorr Apr 17, 2009
- 864 views
I updated from svn today but could not complete the compile.
The compiler (gcc since I am on Linux) found unresolved references in dec2.c (too many to capture easily).
It appears that eui, eub, and eu.a were built, but not euc.
I did not find anything that looked like this in the Bug Tracker. Should I add it?
2. Re: Compile problem with 1943
- Posted by DerekParnell (admin) Apr 17, 2009
- 858 views
The compiler (gcc since I am on Linux) found unresolved references in dec2.c (too many to capture easily).
I just built 1943 on Windows (Watcom) without any problems.
What is just one of the unresolved references you are seeing?
3. Re: Compile problem with 1943
- Posted by jeremy (admin) Apr 17, 2009
- 855 views
I updated from svn today but could not complete the compile.
The compiler (gcc since I am on Linux) found unresolved references in dec2.c (too many to capture easily).
It appears that eui, eub, and eu.a were built, but not euc.
eubins seems to have built 1943 OK. What version of eui did you use to build the new? Maybe it had an issue.
I did not find anything that looked like this in the Bug Tracker. Should I add it?
Yes, please do with as much information as you can. We can then look at it in detail and take the correct action. Do not hesitate to add bugs if you think something is wrong. If it's not, we can close the bug easy enough. Err on the side of reporting bugs
Jeremy
4. Re: Compile problem with 1943
- Posted by georgeorr Apr 17, 2009
- 844 views
last three are undefined references to
_22070 _25link_file_35074 _21492
error summary messages were
collect2: ld returned 1 exit status make[1]: * [/home/george/EU40_2/source/euc] Error 1 make: * [translator] Error 2
5. Re: Compile problem with 1943
- Posted by georgeorr Apr 17, 2009
- 830 views
Sorry the last message got garbled. Guess I needed to force line breaks
Trying again
last three are undefined references to
_22070
_25link_file_35074
_21492
error summary messages were
collect2: ld returned 1 exit status
make[1]: * [/home/george/EU40_2/source/euc] Error 1
make: * [translator] Error 2
6. Re: Compile problem with 1943
- Posted by jeremy (admin) Apr 17, 2009
- 849 views
last three are undefined references to
_22070
_25link_file_35074
_21492
error summary messages were
collect2: ld returned 1 exit status
make[1]: * [/home/george/EU40_2/source/euc] Error 1
make: * [translator] Error 2
Can you paste the version number of eui? (Just type eui by itself).
Jeremy
7. Re: Compile problem with 1943
- Posted by bernie Apr 17, 2009
- 840 views
The compiler (gcc since I am on Linux) found unresolved references in dec2.c (too many to capture easily).
I just built 1943 on Windows (Watcom) without any problems.
What is just one of the unresolved references you are seeing?
Derek: I have been using the changes SVN1936-SVN1943 to build default windows on XP and testing them on WIN98.
I get the following error when running a program that works ok on SVN1705.
But I had no problem building the binaries.
Also note the error said "Can't create error message file: ex.err"
The ex.err is there but it is an empty file.
---------------------- TASK ID 0 initial task ---------------------------- C:\EU_MASTER\INCLUDE\std/memory.e:114 in function allocate() type_check failure, Can't create error message file: ex.err Press Enter...
8. Re: Compile problem with 1943
- Posted by georgeorr Apr 17, 2009
- 835 views
The eui on my path is version 1931
The eui built from the svn is version 1943
last three are undefined references to
_22070
_25link_file_35074
_21492
error summary messages were
collect2: ld returned 1 exit status
make[1]: * [/home/george/EU40_2/source/euc] Error 1
make: * [translator] Error 2
Can you paste the version number of eui? (Just type eui by itself).
Jeremy
9. Re: Compile problem with 1943
- Posted by jeremy (admin) Apr 17, 2009
- 858 views
The eui on my path is version 1931
The eui built from the svn is version 1943
Can you please try something before 1914 or try building 1943 from a 1943 build on eubin? Starting on 1914 we had some problems with SVN head that took a bit to get figured out. I am not sure of the exact revision when things were finally OK.
Jeremy
10. Re: Compile problem with 1943
- Posted by georgeorr Apr 17, 2009
- 911 views
Jeremy
I got the 1943 binaries and tried again. With eui 1943 I am still getting the same results.
My wife says I have to to to dinner now. I'll check back as soon as I can.
George
The eui on my path is version 1931
The eui built from the svn is version 1943
Can you please try something before 1914 or try building 1943 from a 1943 build on eubin? Starting on 1914 we had some problems with SVN head that took a bit to get figured out. I am not sure of the exact revision when things were finally OK.
Jeremy
11. Re: Compile problem with 1943
- Posted by mattlewis (admin) Apr 18, 2009
- 890 views
Jeremy
I got the 1943 binaries and tried again. With eui 1943 I am still getting the same results.
My wife says I have to to to dinner now. I'll check back as soon as I can.
George,
Have you tried a "make clean" before building? I believe that the issue has to do with some changes that were made to the translator. There were some major refactorings, which caused a different set of c files to be translated, which sometimes confuses the build process (to figure out which c files need to be compiled and linked).
Matt
12. Re: Compile problem with 1943
- Posted by georgeorr Apr 18, 2009
- 864 views
Matt -
That did it! I shall add using "make clean" before building to my checklist in the future!
Thanks
George
Jeremy
I got the 1943 binaries and tried again. With eui 1943 I am still getting the same results.
My wife says I have to to to dinner now. I'll check back as soon as I can.
George,
Have you tried a "make clean" before building? I believe that the issue has to do with some changes that were made to the translator. There were some major refactorings, which caused a different set of c files to be translated, which sometimes confuses the build process (to figure out which c files need to be compiled and linked).
Matt
13. Re: Compile problem with 1943
- Posted by SDPringle Apr 18, 2009
- 902 views
If you need to do a make clean to get consistent results then your Makefile has an issue. You need to have the dependencies set properly in the Makefile. I never need to do a 'wmake -f makefile.wat clean' with Windows. Maybe we should standardize with watcom-make...
Shawn Pringle
14. Re: Compile problem with 1943
- Posted by jimcbrown (admin) Apr 18, 2009
- 846 views
If you need to do a make clean to get consistent results then your Makefile has an issue. You need to have the dependencies set properly in the Makefile. I never need to do a 'wmake -f makefile.wat clean' with Windows. Maybe we should standardize with watcom-make...
Shawn Pringle
Actually, I have had this problem consistently with watcom wmake.
I tracked it down to the fact that it's not deleting the old .c or .obj files, which I assume was a 98 specific issue.
15. Re: Compile problem with 1943
- Posted by SDPringle Apr 18, 2009
- 830 views
I don't believe it should need to delete old *.obj or *.c files. If the object file will be included iff the objfiles.lnk file contains it. The object file will be updated iff the C file is recreated, that is to say if it is created by the translation process. That's the way it should work at least. If not, the problem is not deleting, the problem is dependencies again. Look at the general rule for C to OBJ. The problem must be there.
Shawn Pringle
16. Re: Compile problem with 1943
- Posted by mattlewis (admin) Apr 18, 2009
- 811 views
If you need to do a make clean to get consistent results then your Makefile has an issue. You need to have the dependencies set properly in the Makefile. I never need to do a 'wmake -f makefile.wat clean' with Windows. Maybe we should standardize with watcom-make...
It's rarely necessary with GNU make either. I'm pretty sure that at some point it made sure to remove all the *.c files in the target translator directory, but there have been a lot of regressions within the GNU makefile (usually due to changes related to djgpp issues). This is probably one of them.
I think the plan is to start using the makefile option when translating, and get the dependencies from there. The downside is that I believe it requires yet another recursive call to make. I could be wrong on that.
I can't figure out what you mean by 'standardize on watcom-make.'
Matt