Process terminated with status 1 ???

[Galvatron]

Sorry, forgive me ,still new .. please help me!

Project   : Console application
Compiler  : GNU GCC Compiler (called directly)
Directory : C:\Documents and Settings\Personal\Desktop\
--------------------------------------------------------------------------------
Switching to target: default
Linking console executable: C:\Documents and Settings\Personal\Desktop\ntah.exe
.objs\yahoo.o:yahoo.cpp:(.text+0x100): multiple definition of `main'
.objs\cuba2.o:cuba2.cpp:(.text+0x100): first defined here
.objs\yahoo.o:yahoo.cpp:(.bss+0x0): multiple definition of `term'
.objs\cuba2.o:cuba2.cpp:(.bss+0x0): first defined here
.objs\cuba.o:cuba.cpp:(.text+0x100): multiple definition of `main'
.objs\cuba2.o:cuba2.cpp:(.text+0x100): first defined here
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 3 seconds)
0 errors, 0 warnings

That under Code::Blocks Tab,

MessageManager initialized
Manager initialized
ProjectManager initialized
Loading lexer_cg.xml
Loading lexer_cpp.xml
Loading lexer_f77.xml
Loading lexer_gm.xml
Loading lexer_hitasm.xml
Loading lexer_lua.xml
Loading lexer_prg.xml
Loading lexer_rc.xml
Loading lexer_xml.xml
EditorManager initialized
PluginManager initialized
Configured 0 tools
ToolsManager initialized
Scanning for plugins in C:\Program Files\CodeBlocks/share/codeblocks/plugins...
Found 14 plugins: AStylePlugin CBProfiler ClassWizard CodeCompletion CodeStatistics Compiler DebuggerGDB DefaultMimeHandler DevPakUpdater Source HTML, RTF and ODT Exporter HelpPlugin PluginWizard ToDoList WindowsXPLookNFeel
Opening C:\Documents and Settings\Personal\Desktop\console.cbp: done
Concurrent threads for pool set to 1
MacrosManager initialized
Opening C:\Documents and Settings\Personal\Desktop\ntah.cbp: done
Concurrent threads for pool set to 1


What wrong with my compiler?what meaning status 1?How to solving this problem?Thank You.

[Ceniza]

There's nothing wrong with your compiler, in fact it's the linker that is complaining.

It seems to me you're a bit lost about projects. A project is a collection of source files that together make up a whole application (well, that's the idea). If you have many different sources, each one being a separate application, be sure to create a project for each one of them or put them in different targets or just compile each one of them without creating a project.

Since you're just testing small pieces of code, do NOT create a project, create a new empty file, write your code, save it, compile it and run it.

[Biplab]

Linking process has failed in your case. So it's saying "process terminated with status 1", means with an error.

You're using Code::Blocks RC2. Please upgrade to a latest nightly instead.

If you are using Vista, then you may need to manually tweak to get MinGW working. Search in this forum and you'll get the answer.

[rickg22]

Yes, but I have the suspicion he had two different main() functions.

[thomas]

All projects and code one wants to compile should be preferably in root of some drive (for instance in C:\projects or K:\StUff_to-compile) and PATH (folder names) MUST NOT contain any white (blank) spaces as for MinGW and code one plans to compile with MinGW's gcc/g++. Only compilers insensible to blank spaces in paths are Microsoft's and Intel's.

As it is written, this is FUD.
The only program known to have trouble with spaces in filenames is windres.

Regarding the problem, Rick is right, the OP links two source files (main.cpp and yahoo.cpp) which both contain functions with the same names and signatures into the same executable. This produces a linker error, because it's wrong.

[thomas]

You'll always get errors like this. Path is your problem...

Sure Thomas, you're absolutely right about paths. That's why I jump from board to board AND - it must be a miracle! - AFTER they have followed my advice - have been able to compile.

"Path is your problem" is not true, it's as simple as that. Although there may be a problem if one uses windres, this is entirely unrelated in the present situation. The statement about the compiler is outright wrong.

Besides, contrary to what you posted in 2-3 other threads, none of the many include search paths that you quote are really necessary, it is not strictly necessary to install MinGW under C:\mingw (this just happens to be the easiest way), and it is not necessary to place your project directories under the root directory.
I use MinGW (3 different installations) with Code::Blocks under Windows XP every day without defining a single compiler search dir, and I am able to compile everything, step into STL code, etc... Everything just works. None of my project folders are on the hard drive's root (why should they be?).

Search dir tweaks are only needed if the directory structure is not good (or different than "standard"). This can for example happen when upgrading MinGW versions (it has happened to me, trying to manually update).
However, if everything is installed out of the box like it is intended, it works without tweaking one single thing.

Listen T. I haven't said a word about code. Of course that code is crappy...

Nobody said the code is crappy. Galvatron just links two source files that don't belong together (probably by accident).

why should I tell the things said by Biplab? After rick? Huh?

Indeed, why? Rick correctly pointed out the problem, nothing else needed being said