Torque3D 3.7-RC - libogg fails to compile on Linux (OpenSUSE 13.2) #1293

Closed
fr0zi opened this Issue May 1, 2015 · 9 comments

Comments

Projects
None yet
3 participants
@fr0zi

fr0zi commented May 1, 2015

System: OpenSUSE 13.2 (64-bit)
Build system: cmake, make (GCC 4.8)

I've got this error:

../Torque3D-3.7-rc/Engine/lib/libogg/include/ogg/os_types.h:143:32: fatal error: ogg/config_types.h: No such file or directory

It can be fixed by:

  1. Download ogg library source from http://www.xiph.org/downloads/.
  2. Compile it on your machine to create config_types.h from config_types.h.in file.
  3. Copy config_types.h to ../Torque3D-3.7-rc/Engine/lib/libogg/include/ogg/.
  4. Compile Torque3D again.

@crabmusket crabmusket added the Linux label May 2, 2015

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket May 2, 2015

Contributor

Thanks for the steps. Do you think this is something we can fix by modifying Torque or using the platform layer differently? For now I'll add a note on the wiki about this. Which packages did you have to install to compile the engine? It'd be great if you could add it to the section here about it, even if it's marked with some sort of warning.

Contributor

crabmusket commented May 2, 2015

Thanks for the steps. Do you think this is something we can fix by modifying Torque or using the platform layer differently? For now I'll add a note on the wiki about this. Which packages did you have to install to compile the engine? It'd be great if you could add it to the section here about it, even if it's marked with some sort of warning.

@fr0zi

This comment has been minimized.

Show comment
Hide comment
@fr0zi

fr0zi May 3, 2015

I've added required packages section for OpenSUSE 13.2 on the wiki.

Regarding the fix - I don't think any big change is necessary in Torque code. I figured out this issue can be fixed in three different ways:

  1. By adding type definitions for Linux directly to ..Engine/lib/libogg/include/ogg/os_types.h file like it is for other OSes in this file. Please look at the file in my fork repository: 3f44d72
  2. Package libogg-devel contains the needed file config_types.h so it can be simply copied into ../Torque3D-3.7-rc/Engine/lib/libogg/include/ogg/ folder.
  3. The way I described at the beginning - downloading and compiling libogg from source from Vorbis homepage.

fr0zi commented May 3, 2015

I've added required packages section for OpenSUSE 13.2 on the wiki.

Regarding the fix - I don't think any big change is necessary in Torque code. I figured out this issue can be fixed in three different ways:

  1. By adding type definitions for Linux directly to ..Engine/lib/libogg/include/ogg/os_types.h file like it is for other OSes in this file. Please look at the file in my fork repository: 3f44d72
  2. Package libogg-devel contains the needed file config_types.h so it can be simply copied into ../Torque3D-3.7-rc/Engine/lib/libogg/include/ogg/ folder.
  3. The way I described at the beginning - downloading and compiling libogg from source from Vorbis homepage.
@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket May 5, 2015

Contributor

Thanks for that! It sounds like option number 1 makes it the simplest for users - am I right in thinking that means they could compile the engine without running into this issue? If we're doing that for other OSes already maybe we should follow suit. Can you see any downsides with this approach?

Contributor

crabmusket commented May 5, 2015

Thanks for that! It sounds like option number 1 makes it the simplest for users - am I right in thinking that means they could compile the engine without running into this issue? If we're doing that for other OSes already maybe we should follow suit. Can you see any downsides with this approach?

@Azaezel

This comment has been minimized.

Show comment
Hide comment
@Azaezel

Azaezel May 5, 2015

Contributor

Actually, I'd really really suggest option 3, and chucking a copy in the main repo. Windows has taken to no longer including openal in their releases, so that'd be one more thing to package in a shipping build if we were to assume the game was the first one added to the end user's system, so that's 2 O/Ss that we can't assume come with it pre-packaged.

Contributor

Azaezel commented May 5, 2015

Actually, I'd really really suggest option 3, and chucking a copy in the main repo. Windows has taken to no longer including openal in their releases, so that'd be one more thing to package in a shipping build if we were to assume the game was the first one added to the end user's system, so that's 2 O/Ss that we can't assume come with it pre-packaged.

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket May 5, 2015

Contributor

So, compiling ogg into the engine rather than finding a library to link with dynamically? (This question may have betrayed my tiny tiny understanding of how this stuff actually works). Executable/DLL size increase?

Contributor

crabmusket commented May 5, 2015

So, compiling ogg into the engine rather than finding a library to link with dynamically? (This question may have betrayed my tiny tiny understanding of how this stuff actually works). Executable/DLL size increase?

@Azaezel

This comment has been minimized.

Show comment
Hide comment
@Azaezel

Azaezel May 5, 2015

Contributor

As far as I'm aware, barring some very strange O/S setups indeed, so long as a dynamic lib sits alongside an executable, it'll look to that first before checking paths, so simply redirecting output to the relevant directory should serve.

Contributor

Azaezel commented May 5, 2015

As far as I'm aware, barring some very strange O/S setups indeed, so long as a dynamic lib sits alongside an executable, it'll look to that first before checking paths, so simply redirecting output to the relevant directory should serve.

@crabmusket

This comment has been minimized.

Show comment
Hide comment
@crabmusket

crabmusket May 5, 2015

Contributor

Ah, right, so you'd recommend compiling ogg/OAL libs to go next to the exe? Rather than compiling the code into the exe or engine DLL itself.

Contributor

crabmusket commented May 5, 2015

Ah, right, so you'd recommend compiling ogg/OAL libs to go next to the exe? Rather than compiling the code into the exe or engine DLL itself.

@Azaezel

This comment has been minimized.

Show comment
Hide comment
@Azaezel

Azaezel May 5, 2015

Contributor

Seems the safest bet to ensure this kind of thing doesn't crop up again. (And if as folks have suggested a time or two we switch over to OpenAL Soft, we'd need to do so anyway at that point, since that one is LGPL)

Contributor

Azaezel commented May 5, 2015

Seems the safest bet to ensure this kind of thing doesn't crop up again. (And if as folks have suggested a time or two we switch over to OpenAL Soft, we'd need to do so anyway at that point, since that one is LGPL)

@fr0zi

This comment has been minimized.

Show comment
Hide comment
@fr0zi

fr0zi May 5, 2015

Actually, I was also wondering if this is possible to put all the source code of ogg lib into Torque and compile it right next to the engine. It would generate this config_types.h file with the types specific to the machine - regardless if it's 32 or 64-bit. I didn't want to suggest any option since I don't know Torque source so well, but if this option is possible - I think it would be convenient and safe.

fr0zi commented May 5, 2015

Actually, I was also wondering if this is possible to put all the source code of ogg lib into Torque and compile it right next to the engine. It would generate this config_types.h file with the types specific to the machine - regardless if it's 32 or 64-bit. I didn't want to suggest any option since I don't know Torque source so well, but if this option is possible - I think it would be convenient and safe.

This was referenced Sep 16, 2016

@Lopuska Lopuska closed this in #1777 Sep 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment