On this page https://raw.githubusercontent.com/dvdhrm/docs/master/drm-howto/modeset.c someone has published an example on how to properly use the drm api.
I downloaded the source file compiled it with gcc -I/usr/include/drm/ modeset.h -o modeset, marked it as executeable chmod +x modeset and launched it ./modeset
Output:
michael#lord:~/Documents/cpp/modeset$ ./modeset
./modeset: line 1: $'gpchC014\310\b\032\231\253\267+\277\331\022\225I\021': command not found
./modeset: line 17: syntax error near unexpected token `$'\375?\250\001\177\001\001''
./modeset: line 17: `ø?¨
ø?¨
ø?¨ø?¨0ø?¨2ø?¨4ø?¨6ø?¨8ø?¨9ø?¨:ø?¨;ø?¨<ø?¨=ø?¨>ø?¨Pø?¨Rø?¨Tø?¨Vø?¨Xø?¨Zø?¨\ø?¨^ø?¨`ø?¨bø?¨dø?¨fø?¨hø?¨jø?¨lø?¨nø?¨ø?¨ø?¨ø?¨ø?¨ø?¨ø?¨ø?¨ø?¨ ø?¨¢ø?¨¤ø?¨¦ø?¨¨ø?¨ªø?¨¬ø?¨®ø?¨°ø?¨±ø?¨²ø?¨³ø?¨´ø?¨µø?¨¶ø?¨·ø?¨¸ø?¨¹ø?¨ºø?¨»ø?¨¼ø?¨½ø?¨¾ø?¨¿ø?¨ðø?¨òø?¨ôø?¨öø?¨øø?¨úø?¨üø?¨þø?¨ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨Aù?¨Cù?¨Eù?¨Gù?¨Iù?¨Kù?¨Mù?¨Où?¨aù?¨cù?¨eù?¨gù?¨iù?¨kù?¨mù?¨où?¨qù?¨sù?¨uù?¨wù?¨yù?¨{ù?¨}ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨ù?¨Áù?¨Ãù?¨Åù?¨Çù?¨Éù?¨Ëù?¨Íù?¨Ïù?¨Ñù?¨Óù?¨Õù?¨×ù?¨Ùù?¨Ûù?¨Ýù?¨ßù?¨ñù?¨óù?¨õù?¨÷ù?¨ùù?¨ûù?¨ýù?¨ÿù?¨ú?¨ú?¨ú?¨ú?¨ ú?¨
ú?¨ú?¨1ú?¨3ú?¨5ú?¨7ú?¨9ú?¨;ú?¨=ú?¨?ú?¨Qú?¨Sú?¨Uú?¨Wú?¨Yú?¨[ú?¨]ú?¨_ú?¨qú?¨sú?¨uú?¨wú?¨yú?¨{ú?¨}ú?¨ú?¨ú?¨ú?¨ú?¨ú?¨ú?¨ú?¨ú?¨ú?¨¡ú?¨¢ú?¨£ú?¨¤ú?¨¦ú?¨¨ú?¨ªú?¨¬ú?¨®ú?¨Àú?¨Âú?¨Äú?¨Æú?¨Èú?¨Êú?¨Ìú?¨Îú?¨ðú?¨òú?¨ôú?¨öú?¨øú?¨úú?¨üú?¨þú?¨û?¨û?¨û?¨û?¨û?¨û?¨û?¨û?¨ û?¨"û?¨$û?¨&û?¨(û?¨*û?¨,û?¨.û?¨Pû?¨Rû?¨Tû?¨Vû?¨Xû?¨Zû?¨\û?¨^û?¨`û?¨bû?¨dû?¨fû?¨hû?¨jû?¨lû?¨nû?¨û?¨û?¨û?¨û?¨û?¨û?¨û?¨û?¨Ðû?¨Òû?¨Ôû?¨Öû?¨Øû?¨Úû?¨Üû?¨Þû?¨àû?¨âû?¨äû?¨æû?¨èû?¨êû?¨ìû?¨îû?¨ðû?¨òû?¨ôû?¨öû?¨øû?¨úû?¨üû?¨þû?¨ü?¨ü?¨ü?¨ü?¨ü?¨ü?¨ü?¨ü?¨Pü?¨Rü?¨Tü?¨Vü?¨Xü?¨Zü?¨\ü?¨^ü?¨pü?¨rü?¨tü?¨vü?¨xü?¨zü?¨|ü?¨~ü?¨ü?¨ü?¨ü?¨ü?¨ü?¨ü?¨ü?¨ü?¨°ü?¨²ü?¨´ü?¨¶ü?¨¸ü?¨ºü?¨¼ü?¨½ü?¨¾ü?¨¿ü?¨Ðü?¨Ñü?¨Òü?¨Óü?¨Ôü?¨Õü?¨Öü?¨×ü?¨Øü?¨Ùü?¨Úü?¨Ûü?¨Üü?¨Ýü?¨Þü?¨ßü?¨àü?¨áü?¨âü?¨ãü?¨äü?¨æü?¨èü?¨éü?¨ëü?¨ìü?¨íü?¨îü?¨ïü?¨ ý?¨"ý?¨$ý?¨%ý?¨&ý?¨'ý?¨(ý?¨)ý?¨*ý?¨+ý?¨,ý?¨-ý?¨.ý?¨/ý?¨#ý?¨Aý?¨Bý?¨Dý?¨Fý?¨Gý?¨Hý?¨Iý?¨Jý?¨Lý?¨Ný?¨pý?¨rý?¨tý?¨vý?¨xý?¨yý?¨zý?¨{ý?¨|ý?¨~ý?¨ý?¨ý?¨ý?¨ý?¨ý?¨ý?¨ý?¨ý?¨ý?¨ý?¨¡ý?¨£ý?¨¥ý?¨§ý?¨©ý?¨«ý?¨¬ý?¨ý?¨®ý?¨Àý?¨Âý?¨Äý?¨Æý?¨Èý?¨Êý?¨Ìý?¨Îý?¨ðý?¨òý?¨ôý?¨öý?¨÷ý?¨øý?¨ùý?¨úý?¨ûý?¨üý?¨ýý?¨ÿý?¨þ?¨þ?¨þ?¨þ?¨þ?¨þ?¨þ?¨þ?¨þ?¨?¨þ?¨þ?¨þ?¨ þ?¨"þ?¨#þ?¨$þ?¨%þ?¨&þ?¨(þ?¨*þ?¨+þ?¨,þ?¨-þ?¨.þ?¨/þ?¨#þ?¨Aþ?¨Bþ?¨Cþ?¨Eþ?¨ß#¨#¨#¨#¨#¨#¨#¨#¨#¨#¨Þ#¨ #¨Gþ?¨Hþ?¨Jþ?¨Lþ?¨Nþ?¨`þ?¨bþ?¨dþ?¨fþ?¨hþ?¨jþ?¨lþ?¨nþ?¨ þ?¨¢þ?¨¤þ?¨¦þ?¨¨þ?¨ªþ?¨¬þ?¨þ?¨®þ?¨¯þ?¨'
^[[?1;2c^[[?1;2c
I do not understand this low level framebuffer example so I am a bit lost right now. The web is also not revealing any docs. Some basic hints about what's happening here would be enough.
I am also using xorg server.
The file you are invoking seems not to be a valid ELF executable, bash tries to process it as a bash script and fails. You can check for sure by using file command, e.g. file modeset.
Check for the errors during your GCC build. Note that you try to compile modeset.h, not modeset.c.
Related
Problem in short - In Linux, whenever we get the following error
"Syntax error: word unexpected (expecting ")")", what does it generally mean?
Problem in details - I have been trying to cross-compile Qt 4.6 as per the Sourcery tool chain on Ubuntu 10.04 (Lucid Lynx). I followed the exact steps mentioned at the link compiling Qt-4.6. But I get the following error right in the ./configure step -
/home/weds/qt-everywhere-opensource-src-4.6.1/bin/qmake: 1: Syntax error: word unexpected (expecting ")")
Searching on the Internet I found lots of posts regarding this error and read all of them. What is this error and how can I solve it?
P.S 1 - the Sourcery toolchain is present inside /opt/ folder and my PATH variable is correctly pointing to it.
P.S 2 - This toolchain was not installed manually by me. Rather it was provided by a vendor as a .tgz file which I extracted inside the /opt/ folder.
That's an error reported by the Almquist shell or any of its derivatives like Dash (and Dash happened to be the default implementation of /bin/sh on Ubuntu 10.04 (Lucid Lynx)) when a word is found while parsing the syntax of a script where a ) is expected instead, for instance like in this case statement:
dash -c 'case a in b c) :; esac'
dash: 1: Syntax error: word unexpected (expecting ")")
That's because after b , the only thing that is expected after is ), (though actually | would also be allowed) so that c word is unexpected.
dash -c 'myfunc( something'
dash: 1: Syntax error: word unexpected (expecting ")")
One case where that can happen is if the script has been written on or transferred through a Microsoft OS where text line endings are CRLF instead of just LF.
A
case a in b) cmd1;;
c) cmd2
esac
script written on MS-DOS would appear as:
case a in b) cmd1;;<CR>
c) cmd2<CR>
esac<CR>
on Unix and that c would be an extra word after the <CR> word.
Here that's unlikely as your error reports the problem being on the first line of the script and most scripts start with the #! /path/to/interpreter shebang line.
Another possibility is that that script you're trying to run has been written on the assumption that sh was bash and uses constructs that are not portable to other sh implementations.
Since you're using an outdated and no longer maintained OS, it's also possible that you're running into a bug in that version of Dash. You could run dpkg-reconfigure dash and tell the system not to use Dash for sh (but Bash instead) to see if that helps.
Again, it is unlikely to be on the first line.
What sounds more likely is that that qmake file is not a script, but a binary executable that is not recognised as such by the system, for instance because it is of a binary format for the wrong architecture or it has been corrupted in transfer.
In that case, when the system fails to recognise it as a native executable, the invoking application would try to run sh on it as if it was a shell script, and the presence of a ( character in the file could cause Dash to fail with such an error.
On my system:
dash /bin/touch
/bin/touch: 1: /bin/touch: Syntax error: word unexpected (expecting ")")
And if you look at the content of /bin/touch as if it were a script, you see:
^?ELF^B^A^A^#^#^#^#^#^#^#^#^#^B^#>^#^A^#^#^#5&#^#^#^#^#^##^#^#^#^#^#^#^#(ô^#^#...
An answer to this seems to be posted in the instructions to which you linked.
Admittedly it's a long way down in the comments but it didn't take long to search for qmake: Syntax error: word unexpected.
Quote:
Tej says: January 4, 2013 at 12:20 pm
Ok, I have solved the Problem. Its very unfortunate that ppl did not
tell what actually is the problem. Problem is we have to use Host
qmake. For that whatever Export (export
PATH=/usr/local/arm/4.3.2/bin:$PATH etc.) we did in step during tslib
installation, we have to undo all of that. Thats it.
Hope that help someone
In case that's not clear, Tej suggests that it would seem that you're trying to run the cross-compiled qmake on the host system.
In 99% of the cases it is a wrong file transfer mode, ASCII or binary.
Try to extract the toolchain directly on the target system.
I was writing a C++ program on Ubuntu 18.04 (Bionic Beaver) when this problem came around. The cause was that the file name of the program contained the characters "(" and ")". After renaming the files, it worked for me.
This error can also be thrown when calling a NodeJS script from a shell script, without providing the correct shebang line in NodeJS:
#!/usr/bin/env node
// Rest of your NodeJS script
A weird fix for me was deleting file package-lock.json and the node_modules folder, and then building the Docker image again.
Sometimes this error occurs just because the directory in which you are currently working has "wrong naming convention" .. like it could be
demo_project (copy)
my_project_1 (another copy)
The correct naming convention says
1. demo_project_copy
2. my_project_1_another_copy
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.
I have a problem with compiling and running C codes in notepad++.
I am using the nppexec plugin and wrote the following in the script section after pressing F6:
C:\MinGW\bin\gcc.exe -g "$(FULL_CURRENT_PATH)" -o "$(CURRENT_DIRECTORY)\$(NAME_PART).exe"
$(CURRENT_DIRECTORY)\$(NAME_PART).exe
After pressing OK, I get the following on the console:
C:\MinGW\bin\gcc.exe -g "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.C" -o "D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe"
Process started >>>
<<< Process finished. (Exit code 0)
D:\Silent\Documents\College Stuff\6th sem\NETWORKING lab\substitutioncypher.exe
Process started >>>
Here, substitution.c is my program to be run. The problem is that the gcc part is working fine but I am not able to execute the program from here as there is no response.
As you see, it just says process started and after that nothing. No response to a key being pressed, it just accepts everything like a text editor.
If I go to the working directory and execute the program from there (double clicking the exe file) then it seems to run perfectly fine. The problem seems to be in my script or the plugin.
Please, can anyone find out what is wrong with my compiling and running script?
In addition to #paxdiablo 's answer, you may also find useful the following NppExec script for single file projects:
npp_save
cd "$(CURRENT_DIRECTORY)"
cmd /c del "$(NAME_PART)".o "$(NAME_PART)".exe *.o
C:\MinGW\bin\gcc.exe -g3 -std=c89 -pedantic -Wall -Wextra -Wno-nonnull "$(NAME_PART)".c -o "$(NAME_PART)".exe
npp_run "$(NAME_PART)".exe
The 1st line saves the document that is currently active inside notepad++.
The 2nd line ensures your current directory is the one of the active document. This let you refraining from using the "$(CURRENT_DIRECTORY)" variable in the rest of the lines.
The 3rd line removes any executables and object-file leftovers from previous successful compilations. Removing the last executable is a nice idea, because if you don't then the last line will cause your .exe produced by the last compilation to be run anyway, even if your current compilation fails. A failed compilation does not produce an .exe, so normally you don't want NppExec to run the previous .exe. Removing the previously produced object-file is optional, but it does ensure that it will not affect fresh compilations (it makes more sense in multi-file projects, as an alternative to the touch command-line tool).
The 4th line compiles the active document. Feel free to modify gcc's options according to your needs. If you add C:\MinGW\bin into the Windows PATH environment variable, and assuming you are using only one gcc installation on your system, then you can skip the absolute path, and write just gcc instead.
The last line executes the produced executable. The npp_run command tells NppExec to launch a new command-prompt window, and run your program in it (unless it is a WIN32 GUI program). I personally find it more convenient compared to the NppExec console embed in notepad++. It looks more natural and it also avoids some I/O redirection problems of the NppExec console.
However, if your program is a console app that does not interact with the user say via a loop, then this approach will cause the launched command-prompt window to close immediately after your program terminates, not giving you the chance to inspect its output. In that case you should have you program waiting for a key to be pressed by the user just before its termination. A quick-and-dirty way is to put a system("pause"); right before your main() function's return and/or exit() statements (it is much better though to write a simple cross-platform function or macro for this).
You may experiment with the above script by typing it in F6's <temporary script> and save it permanently for general use when you are happy with its behavior.
On a side note, you may also find it useful to have a look at this post, where I'm trying to explain how to setup NppExec so it jumps to the appropriate line in the source code, by double-clicking on any error gcc spits in the NppExec console during compilation.
This is a n00b question and I've seen an answer that does not help me.
I'm running a simple c program (firsty.c) written in textmate:
#include <stdio.h>
int main()
{
printf("hi world.\n");
return 0;
}
I've entered the following into the terminal with the following results:
$ make firsty.c
make: Nothing to be done for `firsty.c'.
$ ./firsty.c
./firsty.c: line 3: syntax error near unexpected token `('
./firsty.c: line 3: `int main()'
probably something simple, but I don't understand what's wrong.
make firsty.c isn't doing anything at all. Try instead make firsty, and then ./firsty.
You are trying to execute the source file. You need to execute the binary file which was hopefully built by make.
I do not know what your makefile is doing, however if it's something like gcc firsty.c the binary output file will be named a.out by default. Use gcc -o executable_name_here to have differently named output file (http://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options)
Unix (osx at this time) is considering executable file a script, and tries to execute it. On other thing to do would be to remove executable permissions from your source file and then you will not be able to run it.
I think u have not created any Makefile which is used by make command to compile the given source file(s)... so try to write a makefile(http://www.cs.colby.edu/maxwell/courses/tutorials/maketutor/) else try to compile as...
gcc firsty.c -o firstly
then u'll get the executable file in the same directory & u can execute it as
./firstly
take care of the '#'. when you excute a source code file, the OS maybe excute it with the shell. So we get the syntax error.
Try make firsty, it will work and will make a executable with a name firstly.
If this oes not work, try make ./firstly.
Please note that while doing a make as such you need to supply the name of file only and not the extension as .c
The output file is created with the name of file and it will search for corresponding .c file to compile.
In your case
make firsty
This will look for firsty.c to be compiled and create an output file with name firsty.
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.