Hello :)
I am presently learning SDL2, and I made several programs with it.
With these programs, when I double-click on the executable, the program launches, and everything is okay.
On the last program I made, it doesn't work anymore. With this one, I can only launch from terminal.
The exe has the permissions, so theres no reason for this to happen...
The only thing I changed is that the old generic function file I used (for things like "loadTextureFromImage()"...) to a dynamic library I created. Here's a link to the entire project (just a white window for now) -> RightHere.
I'm currently running Ubuntu 14.04.
If you have any idea on why it doesn't work just for THIS project, tell me please!
Thank you in advance ;)
PS : Here's a project that actually works -> RightHere
PS2 : The projects are in c
Okay, so I did ldd ./myprog, and the libraries linked are where I put them, in "${HOME}/lib". If I understood well, you are telling me that because these libraries aren't in "/usr/lib and so on...", they won't be found, and I should write a script. There's a little thing I forgot to tell : I had to add an environment variable in my .bashrc -> export LD_LIBRARY_PATH=${HOME}/lib, so that the libraries are found at compile-time. Because of what you said, I think that this variable is only loaded in terminals, isn't it? So I tried two scripts :
#!/bin/bash
LD_LIBRARY_PATH=$PWD
./myprog
(like you told) and
#!/bin/bash
LD_LIBRARY_PATH=${HOME}/lib
./myprog
(like I made in my .bashrc).
When I run them by double-clicking on them, neither work.
But, when I run them from terminal, only the second one works.
Thank you for the answer, hope it'll help...
EDIT : I confirm that the variable set in .bashrc are only loaded in terminals : I tested this script ->
#!/bin/bash
echo $LD_LIBRARY_PATH > Run.log
LD_LIBRARY_PATH=${HOME}/lib
echo $LD_LIBRARY_PATH >> Run.log
./Pong
and, when I run it from terminal, Run.log contains this :
/home/yohan/lib
/home/yohan/lib,
but, when I run it from double-click, it only contains
*newline*
/home/yohan/lib
Add export before your variable setting. – keltar
Okay so thank you VERY much, it works now, with this script :
#!/bin/bash
export LD_LIBRARY_PATH=${HOME}/lib
./myprog
Related
I want to understand how the downloaded application of Cygwin relates to the "heart"/"mind" of my system. Yes, I am as green as the Emerald Isles. So, please spare me. Let me give an explanation of the chain of events and my perception of them ("backstory"), so that the motivation for my question can be understood.
Currently, on Cygwin, I can see that it "sees" QUARKy (my [super]username on this comp]. And currently I can see that it (Cygwin) cannot "see" the files contained therein (So there's a, metaphorically speaking: "cognitive dissonance"; somehow it automatically "knows" of QUARKy." yet, it knows nothing of it!). It looks blank when I do the "ls" command when in that directory.
Now, if my memory serves me-- I could swear last time, the FIRST time, I downloaded Cygwin (I had to do a... whatever the appropriate terminology for a "master reset" for a comp. is) I could go into that directory and I could see all of my files-- just like if how it would look to me if I went about accessing the files more conventionally (Do you say "Through a GUI"?). I don't recall doing anything in particular to enable myself to have these privileges.
So, in part, I wonder if I failed to download a package the second time which I had the first. I am certainly having much trouble with the packages this second time around.
I am also wondering if-- though I could swear I am vividly recalling actual experiences of mine-- I am wrong that I ever had such an ability. Therefore, I wonder what "special thing" needs to be done so that Cygwin can see the files contained in this user directory. And I would please like it explained to me how the added special feature enables this privileged. I do see that it should make sense that, having independently downloaded this environment, it should not "naturally" know anything about my comp. But then, it is further striking, I think, that it should know of "QUARKy" and make it a directory. Though, perhaps I place too much weight on this last feature. Afterall, it is just a name and might natural default to making it a directory. Why stop there though?
See how maddening this is for me?!!!
:-( <---- That's what I look like, from now on.
Please help!
Cygwin is not an isolated environment like for example a virtual machine inside VirtualBox. It works on the same filesystem as other Windows applications. Its files could be accessed through any file manager (e.g: Total Commander), and it can access any other file including your home folder in Windows.
Only one thing makes confusion: cygwin uses UNIX-like paths but Windows uses DOS paths. There is a translation method to convert them vica-versa. cygpath utility can do this translation automatically, but it could be done by head as well. Here is some example:
#############################################
# converting to Windows path format:
#############################################
$ cygpath --windows /
C:\cygwin
$ cygpath --windows /home
C:\cygwin\home
$ cygpath --windows /home/username
C:\cygwin\home\username
$ cygpath --windows /cygdrive/c
C:\
#############################################
# converting to Cygwin (UNIX) path format:
#############################################
$ cygpath --unix 'C:\Users\username'
/cygdrive/c/Users/username
$ cygpath --unix 'C:\Windows'
/cygdrive/c/Windows
$ cygpath --unix 'D:\Games'
/cygdrive/d/Games
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 installed OpenSceneGraph 3.0.1using MacPorts.
I've tried osgversion -> OpenSceneGraph Library 3.0.1. I downloaded the OpenSceneGraph-Data.
Everything seems working well than osgviewer cow.osg takes hours without viewing anything !
please I need help ? is there a way to debug ?
Make sure you have defined the OSG_FILE_PATH environment variable and that it points to the data directory (the one with 'cow.osg').
You can then set OSG_NOTIFY_LEVEL to DEBUG_INFO to get extended information printed to the console. If for any reason the file could not be loaded correctly you will see where to start to troubleshoot.
You can also try to run
$ osgviewer --image /path/to/an/image.png
to test if the plugins work correctly.
Plugins are named e.g. osgdb_jpeg.dylib so you can look for these to make sure they have been built properly along with the core libraries and programs.
Try setting the notify level to DEBUG : Tips And Tricks
$ export OSG_NOTIFY_LEVEL=DEBUG
and run it and see if it says what's going on/going wrong.
I have looked through both the CodeBlocks and MinGW FAQ and wiki to no avail. As stated above I am a noob.
I want CodeBlocks to act like a Unix compiler in that it overwrites a single output file every time it compiles unless told to do otherwise.
In Unix:
[cc example.c] -> [a.out], [cc example2.c] -> [a.out]. If I want to save the output file from being overwritten i just [cc -o newname example3.c] - [newname.out].
If this is possible with CodeBlocks/MinGW on XP I'd like to know how to do it. If not I would appreciate recommendations for another GUI compiler/IDE that could. Any help is appreciated. Thank you.
I want CodeBlocks to act like a Unix
compiler in that it overwrites..
First of all, C::B isn't a compiler -- it's an IDE. Saying you want C::B to act like a compiler makes no more sense then saying you want vim, emacs, or visual studio to 'act' like a compiler.
Second, you change the name of the final executable by right-clicking a project in your workspace. Goto properties->Build targets tab->select which build target you want to change. On the right side of this you'll see Output filename. Enter the executable filename the linker should output here. Alternatively, you can just navigate to the location of your existing executable and just rename it to something else.
And thirdly, chances are you're not even going to be checking back on this site so I'm probably just wasting my time giving an answer to your post.
I'm just starting programming and going through K&R to try and learn C. I've gotten to the section on command line arguments (5.10) but now I'm stumped. Every time I try and open a program I've written with command line arguments I'm told that file X, X being the argument, doesn't exist.
`gcc -o find find.c
open find test
The file /Documents/Learning_C/test does not exist.`
Any suggestions? Thanks
What system are you on? In Unix/Linux you compile & run your executable via:
gcc -o find find.c
./find test
As others have noted, when you prefix your binary with "./", there wont be any naming conflicts. However, if you made find accessible in your $PATH, you might have some conflicts with find and test--standard programs with most *nix distributions... Maybe you could choose more specific names (i.e. ./myFind testArg)
Try giving your output executable a different name.
I suspect your executing the system find command which is looking for a directory called 'test'.
Or try forcing it by executing
./find toto
Edit: Prepending the ./ to the command is important because it tells the shell to execute the find in the current directory as opposed to the first 'find' that exists in your PATH. It is normally recommended that you don't have . (the current directory) in your PATH for security reasons.
HTH
P.S. Forgot to say good one for working through K&R. I just finished doing the same after working in C for thirty years and it was good to get back and refresh the mind!
Instead of making us all individually guess what exactly you're doing wrong, perhaps you should paste the program you're using for the illustration mentioned ?