I have these files on my dir
Driverhdrs.pm
README
btest.c
dlc
ishow.c
Driverlib.pm
bits.c
btest.h
driver.pl
tests.c
Makefile
bits.h
decl.c
fshow.c
By following the instruction, I type ./dlc bits.c on terminal, but I get ./dlc: cannot execute binary file on macos. I look up the solution online and find that I need to execute on the right OS. However, I have no idea how this works. I also try to compile dlc again, but I do not have the source code.
Could someone please tell me the specific steps on how to solve this?
Thanks in advance
Related
I want to compile this old exploit to complete my exercise: https://www.exploit-db.com/exploits/895/.
After gcc repoted that <asm/page.h> was missing.
I searched around the net and found out that a number of headers in asm have been moved to:
/usr/src/linux-headers-4.0.0-kali1-common/include/asm-generic/
To make sure that the source file had everything it needed to compile, I made a link for each and every file in the above directory to:
/usr/include/asm
/usr/include/asm-generic
I ran gcc, this time, it didn't report missing <asm/page.h> but <linux/compiler.h>
After digging around, I found this:
<asm/page.h>
|
|---#include <asm-generic/getorder.h>
|
|--#include <linux/compiler.h> ==> missing
A simple locate linux/compiler.h showed me that compiler.h was in here
/usr/src/linux-headers-4.0.0-kali1-common/include/linux/compiler.h
Surely, I could make another link from that <linux/compiler.h> to /usr/include/linux.
But I don't really know how many of them are left and how many more links I have to make.
Is there any way to tell the compiler that it must fetch the header from the new include directory?
Or Am I missing something here?
I'm still new to linux, so any help is appreciated.
Note: I'm using Kali 2.0 64 bit and have installed/reinstalled build-essential
UPDATE:
I tried -I option:
gcc source.c -m32 -I /usr/src/linux-headers-4.0.0-kali1-common/include/
This time, gcc said that I need something from
/usr/src/linux-headers-4.0.0-kali1-common/arch/x86/include/
(=.=)
I'm trying to find a way to convert simple C code to NASM assembly. I have tried using objconv and downloaded and unzipped and built it since I am using a MAC; however, it doesn't seem to be working. I keep getting "-bash: objconv: command not found". Does anyone know another way or can help me solve the -bash error.
Bash is the program that takes the words you type in a terminal and launches other programs. If it is reporting an error, it is because it cannot find the program you want to run (at least in this case).
You need to either find a pre-packaged installation of objconv, or you need to do the work to "integrate" your copy of objconv yourself.
If you can identify the executable you want to run (probably called objconv) you need to add that to your path. The easiest way (if it is just for you) is to verify that your ~/.bashrc or ~/.bashprofile has a line that looks something like
PATH=$PATH:${HOME}/bin
Don't worry if it doesn't look exactly the same. Just make sure there's a ${HOME}/bin or ~/bin (~ is the short version of ${HOME}).
If you have that then type the commands
cd ~/bin
ln -fs ../path/to/objconv
and you will create a soft link (a type of file) in your home binary directory, and the program should be available to the command line.
If you create the file, and nothing above has any errors, but it is not available to the command line, you might need to set the executable bit on your "real" (not link) copy of objconv.
If this doesn't work, by now you should be well primed for a better, more specific question.
If you have gcc installed, try gcc -masm=intel -S source.c to generate assembly files in a syntax very similar to that of MASM.
Hello everyone I'm learning C and am trying to figure out how to run it through the command console cmd. I have eclipse installed along with Mingw and added these to the path:
C:\MinGW\bin\;C:\MinGW\msys\1.0\bin
I wrote this program on notepad++ for a quick test run and save it to C:\test.c and also under a folder C:\Users\Pikachu\Music\C code while I was trying to figure it out:
#include <stdio.h>
int main()
{
printf("Hey, Buddy!\n");
return 0;
}
On the cmd console I typed:
c:\>gcc test.c
and got the error message:
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/id.exe: cannot ope
n output file a.exe: Invalid argument
collect2.exe: error: ld returned 1 exit status
When I typed:
c:\>cd c:\Users\Pikachu\Music\c code
and then:
gcc test.c
it just skipped a line as if nothing happened and went back to square one:
c:\Users\Pikachu\Music\c code>gcc test.c
c:\Users\Pikachu\Music\c code>
I was wondering if anyone knows what's going on and could help me out, I'd be so happy if I could see "Hey, Buddy" from cmd! Does anyone also know why I get the error message running it from c:\ and nothing when I run it from the Music\c code\test.c folder even though I'm supposedly running the same file test.c?
I've tried searching around and have picked up references on how the computer can't link to the proper dll's however I'm not sure how to implement this to my specific problem.
Oh and curiously enough when I tried to save another file in c:\ I got a message saying that I didn't have permission to do that even though 5 minutes prior I had done just this. Any insights?
Thanks for your help!
When you run gcc on your C source file, all that it will do it generate an executable file. I believe its called a.exe by default but I would recommend naming it with the -o option:
gcc text.c -o test.exe
Once your file is successfully compiled, run the executable to say hello to the worls:
c:\Users\Pikachu\Music\c code> .\test.exe
As for the first error you got, maybe it has to do with gcc not being able to create the output executable on the root c: folder. I would recommend doing your coding some folder your user owns instead of on a system folder for this reason.
By the way, gcc supports many other options. I highly recommend using -Wall to turn on warnings and choosing what version of the C standard to follow (-std=c99 or -ansi, together with the -pedantic flag).
I'm trying to accelerate a key function in a c project (not c++) using CUDA.
For some reason, i can't get the Makefile's to recognise the .cu extension when I change the name of one of the files to .cu.
It's using a configure script and .am/.in/.deps files, which I don't really understand all that well, but basically I grepped references to file.c and changed them all to file.cu, but it produces a file.o: File Not Found error.
Top level make file
https://www.dropbox.com/s/g282qvbdu8pdas0/Makefile
Src folder makefile
https://www.dropbox.com/s/b4pq026od8gauqi/Makefile
The search command I used was
grep -R -i "file.c"
and I simply changed them all to file.cu, then re-ran configure, make clean, make all - result is File Not Found.
I suppose it must be something to do with extensions being ignored/accepted by the Makefile, but as it's been a long time since I've programmed in C and I've never used such complex Makefiles I don't know how to fix it.
Any ideas?
*PS Also, file.cu has compile errors at the moment, but the error message I'm getting is File Not Found, so I think that's not the problem.
You need to have a rule to build o file from a cu file:
cudafile.o: cudafile.cu
nvcc $(NVCC_FLAGS) -c %< -o $#
So you also need to specify the rule for the cu file, and use nvcc for compilation.
The following guide seems to cover it...
http://mcclanahoochie.com/blog/2011/02/automake-and-cuda/
Actually, most of the advice given in the link seems unnecessary for basic compilation, but for some reason I found that when I re-created the config file using autoconf it worked. No explanation comes to mind.
hello everyone
i try to debug a program, which have been installed by makefile.
it have a binary file of OpenDPI_demo.o and a shell shellscript OpenDPI_demo.
when i gdb OpenDPI_demo.o,i have a problem. i can't run it. the error is:
Starting program: /home/lx/ntop/test/opendpi/src/examples/OpenDPI_demo/OpenDPI_demo.o
/bin/bash: /home/lx/ntop/test/opendpi/src/examples/OpenDPI_demo/OpenDPI_demo.o：can't execute the binary file.
please tell me why. actually i can run the program by ./OpenDPI_demo.
thank you.
Based on the extension, the file is an object file. It is used by the linker (alongside other object files) to produce an executable. It's the real executable the one you want to run/debug.
This is another example of difficulties encountered with programs using libtool.
the file OpenDPI_demo alongside OpenDPI_demo.o is actually, as you said, a shell script which wraps the execution of the real compiled file, probably in .libs/OpenDPI_demo.
libtool needs this wrapper to adjust the runtime library paths and such so that you can execute the program transparently, as if it was actually installed on your system.
The way to correctly debug this application is not
/home/lx/ntop/test/opendpi $ gdb src/examples/OpenDPI_demo/.libs/OpenDPI_demo
but rather using libtool --mode=execute on the shell script, like the following (it's an example):
/home/lx/ntop/test/opendpi $ ./libtool --mode=execute gdb --args \
src/examples/OpenDPI_demo/OpenDPI_demo -f capture.pcap
Suggest you use
gdb OpenDPI_demo
instead
In your makefile if it depens on the object, make it depend on OpenDPI_demo, e.g.