• Advertisement
Sign in to follow this  

Porting project to linux issue

This topic is 4041 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a project that has been developed on Windows using as much non-OS dependent code as I could. For the first time I tried to compile it on under linux. To my surprise I had almost no trouble at all getting it to compile. Only a couple of calls using ZeroMemory() caused hangups, and If need be I'm sure I can write something functionally equal to replace it with. However, one issue did pop up I wasn't ready for, having never really coded anything under Linux before. The program always looks for the application's files in the user's home directory where as the windows counter part looks in the directory the program was launched in. So if I were to try something like Load_Random_File("Titlescreen.tga"); Linux expects the file to be in the home directory which is not at all where I want it to be looking. While I'm sure this is intentional behavior, I don't like it doing this. What I want is for it to mimic the current behavior under Windows. I would also like whatever adjustment to work for Windows as well, that way I can continue to use the exact same code for both platforms.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by BenKwood
Load_Random_File("./Titlescreen.tga");

that should work in windows as well.


Sweet, thanks. I'll give it a shot some time tomorrow.

Share this post


Link to post
Share on other sites
Quote:
Original post by Goober King
Linux expects the file to be in the home directory which is not at all where I want it to be looking.


nope. it should use the current/working directory. are you using a shortcut/script or running it from the home directory, ie "./program_folder/app_name"?

Share this post


Link to post
Share on other sites
Actually the problem is probably, as gumpy suggested, that your running your program from a different directory. In which case the solution I wrote above won't work. My bad (It's been a while since I've used unix)

Share this post


Link to post
Share on other sites

Yes, sounds like you're running it from the home directory, OR you may be double clicking it on Nautilus or a graphic file manager that runs the program with the home directory as the working directory as default, try command line if so.

Quote:
Original post by Goober King
... Only a couple of calls using ZeroMemory() caused hangups, and If need be I'm sure I can write something functionally equal to replace it with...


just replace ZeroMemory with memset IE: memset(somearray,0,sizeof(somearraytype)*arrayelementcount).

Regarding your other issue, I just got a similar error, turns out that I have a node class with pointers to it's children, the children get dynamically allocated with new and they get deleted on the destructor, I have a different class that has a member of this class which is meant to be a root node, and I have a vector of this second class that contains the root node.

Well, as things go when I insert a new item into the vector, the existing elements get deallocated in order to reallocate more memory for the new element, which cause the destructor to be called on the existing elements, effectively destroying the tree, when I try to access it a segmentation fault happens.

I also noticed a dumb bug on the destructor, I was doing if(child==NULL) delete child; instead of if(child!=NULL) delete child; which for the reasons descried made the program work most of the time, albeit leaving a HUGE leak, reminded me of your "dead dreams" post and thought it may give you some hints on what could be wrong.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kwizatz

Yes, sounds like you're running it from the home directory, OR you may be double clicking it on Nautilus or a graphic file manager that runs the program with the home directory as the working directory as default, try command line if so.

Quote:
Original post by Goober King
... Only a couple of calls using ZeroMemory() caused hangups, and If need be I'm sure I can write something functionally equal to replace it with...


just replace ZeroMemory with memset IE: memset(somearray,0,sizeof(somearraytype)*arrayelementcount).

Regarding your other issue, I just got a similar error, turns out that I have a node class with pointers to it's children, the children get dynamically allocated with new and they get deleted on the destructor, I have a different class that has a member of this class which is meant to be a root node, and I have a vector of this second class that contains the root node.

Well, as things go when I insert a new item into the vector, the existing elements get deallocated in order to reallocate more memory for the new element, which cause the destructor to be called on the existing elements, effectively destroying the tree, when I try to access it a segmentation fault happens.

I also noticed a dumb bug on the destructor, I was doing if(child==NULL) delete child; instead of if(child!=NULL) delete child; which for the reasons descried made the program work most of the time, albeit leaving a HUGE leak, reminded me of your "dead dreams" post and thought it may give you some hints on what could be wrong.


Running it as ./a.out worked. I was simply clicking the file in Konqueror. Sounds like something I knew once but forgot about. Now I just have to deal with getting a number of textures renamed with the right case. I'm mostly just stoked it more or less works dead on without any changes. There does seam to be some sort of color cast on a couple random quads for some reason but if one function and some harmless odd behavior is all the trouble I have porting my code, then I think I just had a good day.

BTW thanks for the link to help replace ZeroMemory(). I'll check it out soon.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement