for a number of reasons I have to include a fixed file format, "header.f" containing only a format expression:
c
8000 format(/,
& t9,'----------------------------------------------------',/,
& t9,'Some header that i want to include , Tel.555-55555 ',/,
& t9,'----------------------------------------------------')
c
In my main code I have:
include 'header.f'
When compiling on Linux, with Intel compiler, I get the following message:
header.f(6): error #5082: Syntax error, found END-OF-FILE when expecting one of: <END-OF-STATEMENT> ; <LABEL> BLOCK BLOCKDATA PROGRAM MODULE TYPE COMPLEX BYTE ...
How should I end the header file?
Why the same example is working on Windows (using Visual Studio)? Does it depends on some compiling options?
Thank you!
EDIT 1: Obviously adding statically the code written into "header.f" into the main, works like a charm. The problem is the "compilation" of the .f containing nothing but the format.
Unfortunately, I'm one of the folks that include header.f in the compile line. The problem was that I am trying to compile a fixed format file used as an include.
As someone said in the comments, it's not recommendable to use .f extension for include files.
Lesson learned, thanks everyone for the help provided to me!
Related
I'm fairly new to Xcode and have recently gotten an error message that is probably clear to anyone who knows what they're doing, but I am unsure how to react to this one.
I have a project that is mostly C++, with just a few C files in it. Everything was fine until I tried to add some code to find the computer's MAC address. Apple provides a project example (GetPrimaryMACAddress), and I downloaded, built, and tested that. It works just fine.
After that, I simply copied the C source from the Apple example project and included it into my code project. Then I started getting this error message:
I have tried including the IOKit framework explicitly via the linker; no help. I tried adding more #include statement to the Apple example code; no help. I think that I do not understand what the compiler message is telling me regarding importing from module 'Darwin.MacTypes'.
Clicking on the error message took me to a line in usr/include/MacTypes.h:
I'm not clear on how to Import Darwin.MacTypes. I don't really understand how the source code for GetMACAddress could compile so effortlessly in one project and not another. I didn't rearrange nor add nor delete any of the #include statements in the Apple-supplied C file.
I'll bet there is a simple answer that I am just not seeing. How should I react to this error message?
I had a similar problem with types like UInt16 and UInt32. I just included the MacTypes with the following include statement:
#include <MacTypes.h>
This solved all my type-problems for my example c-file.
Let me guess, when you want to compile C++ source, you should create a C++ source file
(On the toolbar: File > New > File.. > Source > C++ File)
I am trying to compile some Fortran code that, according to the documentation, is known to compile with "Intel Fortran Compiler 11." However, when I try to compile the code using the version of ifort that comes with Intel® Fortran Composer XE 2013 for OS X (here: http://software.intel.com/en-us/fortran-compilers), I get a number of errors. I suspect that I'm either 1) using a compiler that's incompatible with the exact dialect of Fortran used and/or 2) failing to include some necessary libraries.
I'm not a Fortran programmer, so I'm hoping that someone with more experience will be able to glance at the code and recognize if it's just a simple matter of using a different compiler, setting some compiler options, including some specific libraries, or if I'm missing something else altogether.
The full source code can be found just above the Contents here: http://baydeltaoffice.water.ca.gov/modeling/deltamodeling/models/dsm2/dsm2.cfm
To start with, I'm just trying to compile groups.f in /DSM2_v8_0_6_src/dsm2_v8_0/src/common (which requires that a few other modules be compiled first), but the eventual goal is to compile DSM2_v8_0_6_src/dsm2_v8_0/src/ptm/native/fixedData.f and all of its dependencies.
The syntax I'm using follows this basic pattern:
ifort -c DSM2_v8_0_6_src/dsm2_v8_0/src/common/groups.f
To get a sense of the types of errors I'm encountering, here are a couple of types that occur repeatedly:
groups.f(225): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of:
( * ) :: , . % + - [ : . ** / // .LT. < .LE. <= .EQ. == ...
write(unit_error,*)"Error in matching text pattern:",trim(pattern)
---------------------------------------------------------------------^
groups.f(265): error #5120: Unterminated character constant
& "Error in pattern matching. Implementation count does not equal count in NumberMatches"
------^
Could be F77 or F90 depending on how you have done the formatting. Stack oveflow fomatting requires 4 spaces to start the code. On the line 225, is it indented by 6 or not indented at all. If it is indented by 6 and line 265 is indented by 5 then it is F77.
The other question is whether leading spaces have been stripped when moving from one machine to another. If that is the case then they need to be re-inserted.
On the first line with an error, check the line terminations. All lines should end with either CR LF or just LF. If there is a mix, the compiler will throw a wobbly.
If it is F77, try renaming the files with a .f extension to a .for extension. ifort will then definitely pick them up as f77.
In case this might help point somebody with a similar problem in the right direction, after doing some digging I was able to determine that the code was originally compiled using Visual Studio with the compiler option FixedFormLineLength="fixedLength132". So, using ifort from the command line, I can compile using the following basic pattern (omitting all of the include paths, etc., for clarity):
ifort -c -132 DSM2_v8_0_6_src/dsm2_v8_0/src/common/groups.f
As for the dialect, I later heard from the provider that the code was mostly written in Fortran 77, with some parts later revised to Fortran 90.
I'm trying to compile a UTF-16BE C++ source file in g++ with -finput-charset compiler option but I'm always getting a bunch of errors. More details follow.
My environment(in CentOS Linux):
g++: 4.1.2
iconv: 2.5
Linux language(in Terminal): LANG="en_US.UTF-8"
My sample source file(stored in UTF-16BE encoding):
// main.cpp:
#include <iostream>
int main()
{
std::cout << "Hello, UTF-16" << std::endl;
return 0;
}
My steps:
I read the manual of g++ about the -finput-charset option. The g++ manual says:
-finput-charset=charset
Set the input character set, used for translation from the character set of the input file to the source character set used by
GCC. If the locale does not specify, or GCC cannot get this
information from the locale, the default is UTF-8. This can be
overridden by either the locale or this command line option.
Currently the command line option takes precedence if there’s a
conflict. charset can be any encoding supported by the system’s
"iconv" library routine.
Thus I entered the command as follows:
g++ -finput-charset=UTF-16BE main.cpp
and I got these errors:
In file included from main.cpp:1:
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream:1:
error: stray ‘\342’ in program
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream:1:
error: stray ‘\274’ in program
...(repeatedly, A LOT, around 4000+)...
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iostream:1:
error: stray ‘\257’ in program
main.cpp: In function ‘int main()’:
main.cpp:5: error: ‘cout’ is not a member of ‘std’
main.cpp:5: error: ‘endl’ is not a member of ‘std’
The manual text suggests that the charset can be any encoding supported by 'iconv' routine, thus I guessed the compilation errors might be caused by my iconv library. I then tested the iconv:
iconv --from-code=UTF-16BE --to-code=UTF-8 --output=main_utf8.cpp main.cpp
A "main_utf8.cpp" file is generated as expected. I then tried to compile it:
g++ -finput-charset=UTF-8 main_utf8.cpp
Note that I specified the input-charset explicitly to see if I did anything wrong, but this time a "a.out" was generated without any errors. When I ran it, it could produce the correct output.
Finally...
I couldn't figure out where I did wrong. I searched in the web trying to find out some examples for this compiler option but I couldn't.
Please advise! Thanks!
Further edits:
Thanks, guys! Your replies are quick! Some updates:
When I said "UTF-16" I meant "UTF-16 + BOM". In fact I used UTF-16BE. I have updated the text above.
Some answers say the errors are caused by the non-UTF-16 header files. Here are my thoughts if this is the case: We'll always include some standard header files when writing a C/C++ project, right? Such as stdio.h or iostream. If the G++ compiler only deals with the encoding of the source files created by us but never with the source files in the standard library, then what does this -finput-charset option exist for??
Final edit:
At last, my solution is like this:
At the beginning, I changed the encoding of my source files to GB2312, as "Mr Lister" said below. This worked fine for a while, but later I found it not suitable for my situation because most of the other parts in the system still use UTF-8 for communication and interfaces, thus I must convert the encoding in many places... Not only an overhead of my work, it may also result in some performance decrease in my program.
Later I tried to convert all my source files to UTF-8 + BOM. In this way, Visual Studio in Windows could compile them happily but GCC in Linux would complain. I then wrote a shell script to remove the BOM, and before I want to compile my code with GCC, I run this script first.
Luckily, I don't have to build the code in Linux manually because TeamCity the continuous integration tool is used in my project to generate the build automatically. I could change the build steps in TeamCity to help me run this script before the daily build starts.
With this UTF-8 + BOM + script method, I decide not to edit my source code in Linux, because if I want to do so, I must make sure my code could build successfully before I commit it, which means I must run the script to remove the BOM before I build the code, which means SVN would report EVERY file is modified(BOM removed) thus make it very easy to mistakenly commit a wrong file. To solve this problem, I wrote another shell script to add the BOM back to the source files. Though I still don't edit my code very often in Linux, but when I really need to, I don't have to face the terribly long change list in the commit dialog.
Encoding Blues
You cannot use UTF-16 for source code files; because the header you are including, <iostream>, is not UTF-16-encoded. As #include includes the files verbatim, this means that you suddenly have an UTF-16-encoded file with a large chunk (approximately 4k, apparently) of invalid data.
There is almost no good reason to ever use UTF-16 for anything, so this is just as well.
Edit: Regarding problems with encoding support: The OSes themselves are not responsible for providing encoding support, this comes down to the compilers used.
g++ on Windows supports absolutely all of the same encodings as g++ on Linux, because it's the same program, unless whatever version of g++ you are using on Windows relies on a deeply broken iconv library.
Inspect your toolchain and ensure that all your tools are in working order.
As an alternative; don't use Chinese in the source files, but write them in English, using English-language literals, or simple TOKEN_STYLE_PLACEHOLDERs, using l10n and i18n to replace these in the running executable.
Threedit: -finput-charset is almost certainly a holdover from the days of codepages and other nonsense of the kind; however; an ISO-8859-n file will almost always be compatible with UTF-8 standard headers, however, see the reedit below.
Reedit: For next time; remember a simple mantra: "N'DUUH!"; "Never Don't Use UTF-8!"
I18N
A common solution to this kind of problem is to remove the problem entirely, by way of, for instance, gettext.
When using gettext, you usually end up with a function loc(char *) that abstracts away most of the translation tool specific code. So, instead of
#include <iostream>
int main () {
std::cout << "瓜田李下" << std::endl;
}
you would have
#include <iostream>
#include "translation.h"
int main () {
std::cout << loc("DEEPER_MEANING") << std::endl;
}
and, in zh.po:
msgid DEEPER_MEANING
msgstr "瓜田李下"
Of course, you could also then have a en.po:
msgid DEEPER_MEANING
msgstr "Still waters run deep"
This can be expanded upon, and the gettext package has tools for expansion of strings with variables and such, or you could use printf, to account for different grammars.
The Third Option
Instead of having to deal with multiple compilers with different requirements for file encodings, file endings, byte order marks, and other problems of the kind; it is possible to cross-compile using MinGW or similar tools.
This option requires some setup, but may very well reduce future overhead and headaches.
The error message says the problem is in the include files, so I presume what happens is that the include files are normal UTF-8, but the compiler wants to treat them as UTF-16 because of the compiler switch.
So I'm afraid the solution is to always convert the source to UTF-8 first; perhaps in the makefile. Or to find a solution that doesn't contain include files in other encodings...
Edit:
Maybe a GB encoding would work, if and only if none of the system source files contain any non-ASCII characters. Then you could tell the compiler they were GB encoded without problem.
This does not work because the compiler will also try to read the header files as UTF-16, which they are not.
UTF-16 is not an encoding for bytes. It's an encoding where your basic storage unit is 16 bits large.
When you want to store UTF-16 in a byte sequence you have to choose between UTF-16BE and UTF-16LE.
I'm very new to C++; I've worked with several SDKs now on various applications and every time come across the problem that I can't get the 'example code' to compile. This is a very broad question basically regarding ANY example code that is given over the net - what is the standard procedure to make things compile? I know how to compile code that I've written myself but when given a large project containing several CPP and H files, what do I start with? My first port of call, to open 'main.cpp' in Dev-C++ and hit the 'compile' button generally throws up errors about header files not being available and so on.
I won't give a specific example as this has happened several times. I feel as someone getting to grips with C++ that I would learn a lot quicker if I could start with code that works and tweak it myself rather than having to fumble around building things up piece by piece.
The most recent example is a set of example code provided by a company which 10 files:
-Arial.ttf
-demo_resources.rc
-icon.ico
-main.c
-simple.dsp
-simple.dsw
-simple.exe
-simple.h
-trial.c
-trials.c
Running the .exe file works absolutely fine; however if I open main.c and press compile, I receive many error messages. As an example, the first two lines of code in main.c are:
#include "simple.h"
#include <sdl_text_support.h>
This alone spews the error messages:
1: expected unqualified-id before "public"
1: expected `,' or `;' before "public"
2: In file included from trial.c
Clearly I am doing something very wrong as this code must have compiled for someone else in the past to have generated the .exe file. Again this is not an isolated issue, I have this problem all the time.
Since Dev-C++ is perfectly equipped to deal with plain old C files, I can't see that that is the issue. Secondly, simple.h is definitely included in the correct directory. The second include though, sdl_text_support.h is obviously not in my file list above. I have searched the rest of the SDK and found the file lurking elsewhere. How do I explicitly reference the location of the header file using Dev-C++?
Any general tutorial to how to compile pre-made projects or help of any kind would be greatly appreciated.
I like this page:
http://www.cprogramming.com/tutorial.html
I am not familiar with DevC++, but you cannot assume that if you can open main.c and press a button, then everything will work out. No build system is that smart.
If you write your own code (and you understand compiling and linking) then you can keep your files in order and know exactly how to build everything; someone else's codebase may come with a makefile or some other guide to it's organization, but you'll have to learn how to use a good build system, and the one you're using sounds inadequate.
open the project by simple.dsw instead of main.cpp and it should work .
I have the following very simple application that compiles and runs fine:
EDIT: changed the example to be simpilar to end confusion of the real issue
int main() {
return 0;
}
As soon as I add #include <string> (and not even reference std::string), it fails to compile and I get the following error:
/usr/include/c++/4.1.2/bits/allocator.h:82 error: expected template-name before '<' token
Along with about 456 other, similar errors.
Any ideas? Thanks!
UPDATE:
Line 82 of /usr/include/c++/4.1.2/bits/allocator.h references the template __glibcxx_base_allocator at the location of the error. That template is defined in bits/c++allocator.h. When I search the system for that file, I get 3 hits, but none of them are in /usr/include/c++/4.1.2/bits/ as one would expect.
I have version 3.1.6, 4.1.1, and 4.3.2, but not 4.1.2 as the rest of the includes I am using. I am not sure which one is being used (if any, however, I don't get any error for an unknown file), but it seems the problem may stem from this.
The problem appears to be the installed development packages are not correct or incomplete (not to be confused with corrupt). Forcing g++ to use different include versions corrects that:
g++ -nostdic++ hello.cc -o hello -I/usr/include/c++/3.4.6
All the alternative directories (4.1.1, 4.1.2 and 4.3.2) are incomplete causing inappropriate files to be included causing the unusually errors. For example:
/usr/include/c++/4.1.2/bits/allocator.h requires __glibcxx_base_allocator located in bits/c++allocator.h which is being included from either /usr/include/c++/4.1.1 or /usr/include/c++/4.3.2 and appear to be incompatible. Forcing the compiler to use the only complete set of includes rectifies this.
Almost certainly g++ is detecting .cc as a C source file, not C++ and passes it through to gcc instead of compiling as C++. You can easily test by renaming your file to hello.C. There's also a language parameter to g++ you can use.
EDIT: This seems to work fine in g++ 4.2 with a .cc extension so that might not be it. Do you have any other headers included you aren't showing us? They could be interfering with <string>.
EDIT2: Alternatively your headers might not be set up right. Does this work:
#include <string>
int main()
{
return 0;
}
Errors like this have been heard of to occur when the C++ standard library headers are corrupted/not fully installed – maybe there is even a message referring to a missing include among your 456 other errors.
In any case, make sure that libstdc++-devel, resp. the package containing the C++ standard library header files of your distribution, is properly installed.
Check your include path. The paths can be specified as environment variables or specified on the command line. You could be using an include file from a different compiler or different version of the same compiler.
Also, try using <cstdio> rather than <stdio.h>.
Another suggestion: change <> to "".
This could be error caused at preprocess stage. Just preprocess your cpp file by passing flag -E to gcc and Look at the place the compiler complains.