Scons and dmd error: unrecognized file extension o - build

I am trying to build a "hello world" D project with SConstruct and getting this output:
D:\projects\test>scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly
File "C:\Python27\Scripts\scons.py", line 192, in <module>
scons: Building targets ...
dmd -I. -c -ofsrc\main.o src\main.d
dmd -ofhello.exe src\main.o
Error: unrecognized file extension o
scons: *** [hello.exe] Error 1
scons: building terminated because of errors.
Further I discovered that dmd compiler generates object files with the *.obj extension, rather then *.o and it is not able to handle with *.o files.
Is there a way to make SCons to use default output for dmd object files or to pass *.obj files extension for them? Or this is just a bug?
My SConstruct file:
import os
env = Environment(ENV=os.environ)
env.Object(target = 'hello', source = 'src/main.d')
My platform is Windows 7 x86_64.
dmd vervion is 2.064.2.

You need to tell SCons to use the D compiler, as I dont believe it does so by default. This does more than just load the compiler, it also sets the corresponding Construction Variables, which among other things sets the object file extension that you are asking about.
If you create your environment as follows, then the D compiler and related construction variables will be loaded.
env=Environment(tools=['default', 'dmd'])

Related

cannot compile c++ programs with input and output in eclipse

Whenever I try to build C++ programs that involve I/O, I get errors in Eclipse.
02:19:02 **** Incremental Build of configuration Debug for project SecondProject ****
make all
Building target: SecondProject
Invoking: GCC C++ Linker
g++ -o "SecondProject"
g++: fatal error: no input files
makefile:45: recipe for target 'SecondProject' failed
compilation terminated.
make: *** [SecondProject] Error 1
It compiles just fine for other C++ programs that don't require user input.
However, I can compile just fine when I use the command line without an issue. Why is this happening? Is there a fix for it?
The compiler is attempting to compile SecondProject with no source files. Which is why you observed this:
g++ -o "SecondProject"
g++: fatal error: no input files
Troubleshoot
Verify your project properties in
Properties > C/C++ General > Paths and Symbols
Check that your Source Location and Include paths are setup correctly. If your paths are correct, you should see something like when you build again:
g++ -o "SecondProject" ./<your src folder>/<something>.o ...
Otherwise, create a fresh new C/C++ Project and add the sources again.

C++ error on linux machine: ccpentium: No input files

I am writing a code for MRI scanner where all calculation is being done on a Windows machine, while waveforms are being played using linux.
Inside my code, when I declare
#include <vector>
and try to compile it on linux, I start getting errors like this:
ccpentium: FLASH.cpp: No such file or directory
ccpentium: No input files
Any help would be appreciated.
More detailed error:
export PATH=z:/n4_fsp/tornado/i86/host/x86-win32/bin:C:/WINDOWS/system32:C:/WINDOWS:C:/WINDOWS/system32/Wbem; z:/n4_fsp/tornado/i86/host/x86-win32/bin/ccpentium.exe -O1 -Wall -DTOOL_FAMILY=gnu -DTOOL=gnu -ansi -DVXWORKS -DUNICODE -D_UNICODE -mcpu=pentium -march=pentium -fvolatile -nostdlib -fno-builtin -fno-defer-pop -DCPU=PENTIUM -malign-double -D_CONSOLE -DCEST_OffsetSeries -DBUILD_SEQU -DBUILD_CEST_OffsetSeries -Iz:/n4/pkg -Iz:/n4/tool -Iz:/n4_prod/i86/prod/include -Iz:/n4_deli_vb15a/i86/del
ivery/include -Iz:/n4/x86/prod/include -Iz:/n4/x86/delivery/include -Iz:/n4/pkg/MrServers/MrMPCUSystem/Tornado_i86/target/h -Iz:/n4_extsw/x86/extsw/include -o FLASH.oi86 -c FLASH.cpp
In file included from z:/n4_fsp/tornado/i86/host/x86-win32/lib/gcc-lib/i586-wrs-vxworks/2.9-PentiumIII-010221/include/syslimits.h:7,
from z:/n4_fsp/tornado/i86/host/x86-win32/lib/gcc-lib/i586-wrs-vxworks/2.9-PentiumIII-010221/include/limits.h:11,
from z:/n4_fsp/tornado/i86/host/x86-win32/include/g++-3/stl_algobase.h:49,
from z:/n4_fsp/tornado/i86/host/x86-win32/include/g++-3/algobase.h:36,
from z:/n4_fsp/tornado/i86/host/x86-win32/include/g++-3/vector.h:30,
from FLASH.cpp:33:
z:/n4_fsp/tornado/i86/host/x86-win32/lib/gcc-lib/i586-wrs-vxworks/2.9-PentiumIII-010221/include/limits.h:117:60: limits.h: No such file or directory
ccpentium: FLASH.cpp: No such file or directory
ccpentium: No input files
ccpentium: FLASH.cpp: No such file or directory
ccpentium: No input files
ccpentium: FLASH.cpp: No such file or directory
ccpentium: No input files
idea_make: *** [FLASH.oi86] Error 1
20:03:23 ERROR sde::fDos: <idea_make.exe --unix -f CEST_OffsetSeries.mk i86Release> failed with status=2
20:03:23 ERROR sde idea_make.exe --unix -f CEST_OffsetSeries.mk i86Release failed
20:03:23 INFO sde Copying \n4\i86\prod\lib\CEST_OffsetSeries.i86 to c:\Temp\CEST_OffsetSeries.i86
1 Datei(en) kopiert.
The error is caused by the combination of
-nostdlib
flag which asks the compiler not to use its standard linking environment and missing files from your include paths.
From very recent experience, I was missing two files from the include:
-Iz:/n4/pkg/MrServers/MrMPCUSystem/Tornado_i86/target/h
Eventually, I manually copied them from an updated version, but I do not know whether this is a bug or a 'feature' of the older version, so it still remains to be tested whether the compiled code does not break the scanner.

Scons - build order of Fortran files

Building modules in Fortran needs to be done in a specific order, e.g. if a file A.f needs module defined in B.f, then B.f needs to be compiled first. How can I impose such build order in Scons? If I provide it with a list of source files, it arranges them alphabetically (so A.f is compiled before B.f). I read about Requires() and Depends() functions, but wasn't able to get them to work for me.
I would be happy with just listing source files in order I need them compiled (so disabling reshuffling them in alphabetical order), but any other method would be welcomed as well.
As per Kyle's request, here's my Sconscript and a build log:
# Main program building script
Import('env')
PROGRAM = 'main.exe'
SRC_PREFIX = './src/'
SRC = [ 'array_1D_module.f',
'array_2D_module.f',
'array_3D_module.f',
'thomas_algorithm_module.f',
'histogram_module.f',
'histogram_computer_module.f',
'density_parameters_module.f',
'diffusion3D_aos_z_sub_solver_module.f',
'diffusion3D_aos_y_sub_solver_module.f',
'diffusion3D_aos_x_sub_solver_module.f',
'diffusion3D_aos_solver_module.f',
'nonlinear_diffusion_utilities_module.f',
'nonlinear_diffusion_parameters_module.f',
'derivative_magnitude_computer_module.f',
'nonlinear_diffusion_module.f',
'main_module.f',
'main.f' ]
# Attach prefix to each source file
for i in range( len(SRC) ) :
SRC[i] = SRC_PREFIX + SRC[i]
env.Program(target = PROGRAM, source = SRC)
This produced:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
ifort -o src/array_1D_module.o -c src/array_1D_module.f
ifort -o src/array_2D_module.o -c src/array_2D_module.f
ifort -o src/array_3D_module.o -c src/array_3D_module.f
ifort -o src/density_parameters_module.o -c src/density_parameters_module.f
ifort -o src/derivative_magnitude_computer_module.o -c src/derivative_magnitude_computer_module.f
ifort -o src/diffusion3D_aos_solver_module.o -c src/diffusion3D_aos_solver_module.f
src/diffusion3D_aos_solver_module.f(7): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [DIFFUSION3D_AOS_Z_SUB_SOLVER_MODULE]
use diffusion3D_aos_z_sub_solver_module, only :
------------^
So density_parameters_module.f was compiled before thomas_algorithm_module.f, even though it comes after it in my list.
Is your program (as suggested) using modules? There's a couple of gotchas there:
FORTRANMODDIR needs defining: See http://scons.tigris.org/ds/viewMessage.do?dsForumId=1272&dsMessageId=82725 for a discussion on that.
I found that having source files containing a mixture of module definitions and source code caused a certain amount of confusion.

How to use external .h and .o files in current project with Eclipse CDT

I was given three files to test my project: Test1.cpp SignalMasker.h and SignalMasker.o when Test1.cpp includes the SignalMasker.h file and files from my project. Putting both in the source folder returns undefined references such as:
error: undefined reference to 'SignalMasker::~SignalMasker()'
I tried to use the project preferences and add the .o file to it. Under GCC C++ Linker-> Miscellaneous -> other objects. When selecting a file it inserted a new record as:
"${workspace_loc:/${ProjName}/source/SignalMasker.o}"
Building it didn't seem to resolve the issue so I added to the Linker flags the -l flag and got:
Invoking: GCC C++ Linker
g++ -l -o "uthreads" ./source/Scheduler.o ./source/SchedulerStarter.o ./source/Test1.o ./source/Thread.o ./source/main.o ./source/uthreads.o /home/tom/workspace/uthreads/source/SignalMasker.o
g++: error: uthreads: No such file or directory
make: *** [uthreads] Error 1
So I went back to other objects and replaced the automatic generated variable to:
./source/SignalMasker.o
And building gave me:
make: *** No rule to make target `source/SignalMasker.o', needed by `uthreads'. Stop.
These are all solutions I've found in SO and none seem to work including making a library and trying to include it. Please help.
EDIT: uthreads is also the name of the project.

unable to run cpp file using scons

i am trying to compile a c++ program in scons.
the scons works fine for c program but for c++ its giving the following error.
please can anybody help me about this, who knows about this?
first.cpp
#include <iostream>
int main()
{
std::cout << "hellooo" << std::endl;
return 0;
}
SConstructor
Program('first','first.cpp')
the error:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
o first.o -c first.cpp
sh: o: command not found
o first.exe first.o
sh: o: command not found
scons: done building targets.
what could be the problem in this?
You dont have a compiler for C++ installed, or at least SCons cant find it. Although you would expect SCons to explicitly tell you it cant find the compiler, I think what actually happens is it has a Construction Variable for the compiler that is actually empty, and it uses that to create the command line.
If you do indeed have it installed, you can fix this problem as follows:
env = Environment()
env.Replace(CXX = "/path/to/the/c++/compiler")