I'm working though [http://llvm.org/docs/WritingAnLLVMPass.html][1], trying to write a very simple pass. I've written the pass and compiled it (thanks in part to the Stackoverflow community) but now I'm having trouble running it...
The documentation reads:
To test it, follow the example at the end of the Getting Started Guide
to compile "Hello World" to LLVM. We can now run the bitcode file
(hello.bc) for the program through our transformation like this (or
course, any bitcode file will work):
$ opt -load ../../../Debug+Asserts/lib/Hello.so -hello < hello.bc >
/dev/null Hello: __main Hello: puts Hello: main The '-load' option
specifies that 'opt' should load your pass as a shared object, which
makes '-hello' a valid command line argument (which is one reason you
need to register your pass). Because the hello pass does not modify
the program in any interesting way, we just throw away the result of
opt (sending it to /dev/null).
However when I run the command I get the following issue:
mymachine$./opt -load ../../../Debug+Asserts/lib/Hello.so -hello < hello.bc > /dev/null
Error opening '../../../Debug+Asserts/lib/Hello.so':
dlopen(../../../Debug+Asserts/lib/Hello.so, 9): image not found
-load request ignored. opt: Unknown command line argument '-hello'.
Try: './opt -help' opt: Did you mean '-help'?
Any ideas? I'm running OSX and I suspect that is part of the issue...
It turns out the the command I wanted (from the bin directory) was:
opt -load ../lib/LLVMHello.dylib -hello < hello.bc > /dev/null
and I understand the .dylib is the OSX equivalent of .so - but this was largely guesswork...
Try using an absolute path rather than a relative one? This seems like a relatively obvious "file not found".
Related
Is there a way to retrieve predefined macros from the GCC preprocessor without having to use temporary files (e.g. using pipes)?
There is a similar question here on StackOverflow, but all its answers make use of the command line, while I need to read mentioned data from within a process.
GCC dump preprocessor defines
Google basically returns a lot of answers to the command line version of the question.
When I try to perform the command line trick of directing output to /dev/null on Linux or NUL on Windows using pipes:
RunAndGetOutput("cpp -dM -E < NUL");
... an error occurs:
cpp.exe: error: <: Invalid argument
cpp.exe: warning: '-x c' last input file has no effect
cpp.exe: fatal error: no input files
compilation terminated.
When I execute the same command from the command line all is fine, and a list of defines it printed.
Is there any way I can fix this problem?
I'm not sure exactly sure how NUL behaves under windows, but I assume it is similar to /dev/null in Unix/Linux: /dev/null in Windows?
On my Ubuntu VM I can do:
cpp -dM -E -xc /dev/null
So I assume under windows you could do something like:
cpp -dM -E -xc NUL
This assumes NUL behaves essentially like an empty file. If the output from type NUL is any indicator here, then this is hopefully the case.
Alternatively, if this doesn't work, you could do the cpp command with redirection within a cmd.exe subshell:
cmd.exe /C "cpp -dM -E < NUL"
From the point of view of RunAndGetOutput(), this is just a single cmd.exe command with a few params passed, and no pipes/redirections. But the cmd.exe shell will interpret the passed string as a command, and importantly will understand how to handle the < redirection correctly.
Since you're calling the cpp preprocessor directly, the -E and -xc options are unnecessary (at least this is the case in Linux), but leaving them there won't do any harm.
so I'm new here and i have this problem
I have a project where I have to do a makefile
also I have 3 files , but let's take one at least
this is makefile
333.o: 333.c
gcc -c 333.c
clean: rm *.o hell
this is file I want to compile
#!/bin/bash
echo "enetered number $1 threshold $2"
Error c:1:2 invalid preprocessing directive #!
c:2: expected '=', ',',';','asm' or '_attribute' before string constant
what is wrong? can't figure out
thank you
You are trying to pound a nail with a screwdriver - you are using the wrong tool for the job.
You are trying to speak mandarin to (mono-lingual) frenchman - you are using the wrong language.
The contents of file you are trying to compile indicate that it is a shell script and not a c file. However when make sees that the file has a .c extension, it will try to compile it as if it were a c file, which its contents patently are not.
Before you go further I suggest you look at the differences between compiled and interpreted languages
bash is an interpreted language - there is no need for a compiler at all. Just give the file execute permissions and run it. bash will parse and interpret the file line by line and take the necessary actions
c is a compiled language. Before the source that defines a c program can run, it must be compiled. The compiler parses the .c files and generates binary object files, which contain machine instructions that your CPU directly understands.
To run your bash shell script, I would do the following:
mv 333.c 333.sh ; # rename to prevent any confusion
chmod +x 333.sh ; # give the bash script executable permissions
./333.sh 42 69 ; # run the script - give it some args, since your script references $1 and $2
I'm having some issues with output from a fortran application being executed from within Matlab. We use Matlab to call a number of fortran applications and to display output and results.
I'm using gfortran on OSX to build one of these programs, which does a large amount of file output and a little output to stdout to track progress. stdout output is accomplished mainly through print * statements, but I've tried write( * , * ) as well. The program uses OpenMP, but none of the print * or write( * , * ) statements are performed within OpenMP parallel sections.Everything works fine when the program is executed from a terminal. However, when the program is executed from within matlab, there is no output from stdout. The file output works fine though.
Additionally, the same code, when compiled with Intel's ifort, displays its output in matlab without issue. Unfortunately I don't have regular access to the Intel compiler.
I'm positive that the output is going to stdout (not stderr), and I've tried flushing both from within the code (call flush(6) & call flush(0)), but this doesn't seem to make a difference.
I'm not sure what could be causing this. Any thoughts?
some relevant information:
OS: OSX 10.6.8 (64bit mode)
Matlab: R2012b
gfortran: 4.7.2 (obtained via fink)
compile flags: -cpp -fopenmp -ffree-line-length-0 -fno-range-check -m64 -static-libgfortran -fconvert=little-endian -fstrict-aliasing
EDIT:
I've done some more testing, creating a simple 'hello' program:
program printTest
write (*,*) 'hello'
end program
compiled with...
gfortran test.f90 -o test
which exhibits the same behavior.
I've also tried compiling with an earlier version of gfortran (4.2.1), which produced some interesting results. it executes fine in terminal, but in matlab I get the following:
!./test
dyld: lazy symbol binding failed: Symbol not found: __gfortran_set_std
Referenced from: /Users/sah/Desktop/./test
Expected in: /Applications/MATLAB_R2012b.app/sys/os/maci64/libgfortran.2.dylib
dyld: Symbol not found: __gfortran_set_std
Referenced from: /Users/sah/Desktop/./test
Expected in: /Applications/MATLAB_R2012b.app/sys/os/maci64/libgfortran.2.dylib
./test: Trace/breakpoint trap
This leads me to believe its a library issue. using -static-libgfortran produces the same result in this case.
I believe Matlab is a single threaded application. When you invoke a multithreaded executive, I have seen various issues with piping the output back to Matlab. Have you considered recompiling into a Fortran mex file?
I am not sure a mex file would print to stdout any better than a standalone executable.
There are other options. One is to write(append) all your diagnostics to a file and just look at the file when you want to. Emacs, for example, automatically "revert"s the contents of a file every second or whatever you set the interval to. Another option might be to convert the fortran source into matlab source (see f2matlab) and keep it all in matlab.
bb
According to the system function documentation
[status, result] = system('command') returns completion status to the status variable and returns the result of the command to the result variable.
[status,result] = system('command','-echo') also forces the output to the Command Window.
So you should use '-echo' parameter to the system call to see the output directly in the command window
system(['cd "',handles.indir,'";chmod u+x ./qp.exe',... ';./qp.exe'], '-echo')
or you can assign the stdout to a variable:
[ret txt] = system(['cd "',handles.indir,'";chmod u+x ./qp.exe',... ';./qp.exe'])
How to run executable in Xcode with piped input? For example:
echo "abc" | myexec
I know I can set arguments to my executable in the Executable [name] Info > Arguments tab, but there seems to be no option to prefix it or something.
I see "Use Pipe for standard input/output" in the General tab, but how to work with it? Doesn't seem to change a thing.
I'm using Xcode 3.2.6.
I don't know if this is the most elegant way, but could you have a Shell Script build phase that shunts the output of the first command into a file (echo "abc" > tempfile) and then call your executable with (myexec < tempfile)?
I haven't found much online yet besides this now-broken link that explains the use of "Use Pipe for standard input/output".
This is the un-redirected output (if you don't know what module is, it doesn't matter much):
$ module help null
----------- Module Specific Help for 'null' -----------------------
This module does absolutely nothing.
It's meant simply as a place holder in your
dot file initialization.
Version 3.2.6
Suppose I'd like to redirect that to a file....
$ module help null > aaa.txt
----------- Module Specific Help for 'null' -----------------------
This module does absolutely nothing.
It's meant simply as a place holder in your
dot file initialization.
Version 3.2.6
$ cat aaa.txt
$
Well, it must be on the stderr
$ module help null 2> aaa.txt
This module does absolutely nothing.
It's meant simply as a place holder in your
dot file initialization.
Version 3.2.6
$ cat aaa.txt
----------- Module Specific Help for 'null' -----------------------
$
Hey! It is resetting my redirect. This is really annoying, and I have two questions:
How can I achieve what I want, namely redirecting everything into my file
Why are they doing such a weird thing?
See also this related question.
EDIT: somebody asked in a comment, so some details. This is on AIX 5.3 at 64 bits. I have python 2.6.5 almost fully available. I have both gcc 4.1.1 and gcc 4.5.1 but not many libraries to link them against (the util-linux-ng library, which contains the script version mentioned in an answer fails to compile for the getopt part). I also have several version of IBM XL compiler xlc.
The reason why I didn't specify in the first place is that I was hoping in some shell tricks, maybe with exec, not in an external program.
Try this:
script -q -c 'module help null' /dev/null > aaa.txt
This works in a shell script (non-interactively) using
$ script --version
script (util-linux-ng 2.16)
You may also be able to use expect.
Also see: Catching a direct redirect to /dev/tty.
I'm answering the second question first: as a design choice, module is an eval and they took the (questionable) choice to use stderr/tty instead of stdout/stderr to keep their side of the design easier. See here.
My solution, since I couldn't use any of the other recommended tools (e.g. script, expect) is the following python mini-wrapper:
import pty, os
pid, fd = pty.fork()
if pid == 0: # In the child process execute another command
os.execv('./my-progr', [''])
print "Execv never returns :-)"
else:
while True:
try:
print os.read(fd,65536),
except OSError:
break
Looks like module is writing to /dev/tty, which is always the console associated with the process. If so, then I don't think you can do anything about it. Typically, this is done to guarantee that the person sees the message (assuming that the program was invoked interactively).