MacOSX SDK and glew.h

Questions, problems and discussion about compiling FreeOrion.

Moderator: Oberlus

Post Reply
Message
Author
User avatar
mem359
Dyson Forest
Posts: 214
Joined: Sun Jun 08, 2014 1:18 am

MacOSX SDK and glew.h

#1 Post by mem359 »

I decided to try building a test release from source code.

Found the instructions http://freeorion.org/index.php/Compile_In_Mac_OS_X got the SDK.
I then realized I was missing some of the necessary software libraries http://freeorion.org/index.php/Compile# ... quirements, so I got those.

When I try a test build from XCode, the first thing it does is complain that it can't find GL/glew.h
This is one of the headers in GG/base.h

I can't find it either.
Should it have been part of the SDK?
I can copy it by hand from the GLEW area on my computer, I suppose.
Is there some script which should have done that automatically for me?

In that same GG folder are instructions (by Zach Laine) for using cmake to create GiGi libraries.
Is that something I'll need to do? Or is that a remnant that I can ignore?

EDIT:
Okay, what I should have done was modify the "Header Search Paths" for my MacPorts builds (in /opt/local/include ).
I suggest adding that to the Wiki instructions (that some editing will be necessary).

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: MacOSX SDK and glew.h

#2 Post by adrian_broher »

I don't know what you have done exactly, but
Okay, what I should have done was modify the "Header Search Paths" for my MacPorts builds (in /opt/local/include ).
Is certainly not right. Please retrace your steps.
Should it have been part of the SDK?
It is part of the SDK.
I can copy it by hand from the GLEW area on my computer, I suppose.
You should not.
Is there some script which should have done that automatically for me?
No, there is no script that does this for you. You download the SDK binary, copy it over to your preferred location and run the bootstrap.command and run XCode.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
mem359
Dyson Forest
Posts: 214
Joined: Sun Jun 08, 2014 1:18 am

Re: MacOSX SDK and glew.h

#3 Post by mem359 »

adrian_broher wrote:
Should it have been part of the SDK?
It is part of the SDK.
Now I'm confused. But that led me in the right direction.

I downloaded the SDK, and ran bootstrap.command
There is no file called "glew.h" anywhere in that file structure.
No folder called "GL"
And from pocking around, there should have been a folder called "dep" inside "Xcode". (Nope)

I just ran the bootstrap on a fresh copy, and looked more carefully at the log:
Unzipping dependencies...
tar: invalid option -- 'y'
Try `tar --help' or `tar --usage' for more information.
Done.
Removing archive...
I looked at the bootstrap file, and see this:

Code: Select all

echo 'Unzipping dependencies...'
tar -xyf dep.tar.bz2 -C Xcode
echo 'Done.'
echo 'Removing archive...'
Since "tar" does not have a "y" option, it looks like it failed to unpack the dep.tar.bz2 file, and then erased it anyways.

Looks like the bootstrap.command file needs to have the typo fixed.

(I just ran the tar file, which failed unless I used sudo before the tar -xf. All the missing headers and frameworks are in the now-created Xcode/dep folder.)

EDIT: Just made a github issue
https://github.com/freeorion/freeorion/issues/1376

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: MacOSX SDK and glew.h

#4 Post by Vezzra »

@mem359, which version of OSX are you running on?

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: MacOSX SDK and glew.h

#5 Post by adrian_broher »

@Vezzra, he is right. y (not a valid option) should be j (filter through bzip2).
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
mem359
Dyson Forest
Posts: 214
Joined: Sun Jun 08, 2014 1:18 am

Re: MacOSX SDK and glew.h

#6 Post by mem359 »

Vezzra wrote:@mem359, which version of OSX are you running on?
2010 MBP (Intel i5), OSX 11.6 (El Capitan)

Which means the SDK won't work for me anyways, since the frameworks were compiled for i386 instead of x86_64.
Oh well.
But I can still tinker around with this, and maybe get it working for my laptop.
(Not having the Xcode/dep folder made it a lot more difficult to figure out what was going wrong.)

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: MacOSX SDK and glew.h

#7 Post by adrian_broher »

mem359 wrote:Which means the SDK won't work for me anyways, since the frameworks were compiled for i386 instead of x86_64.
Why is that?
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
mem359
Dyson Forest
Posts: 214
Joined: Sun Jun 08, 2014 1:18 am

Re: MacOSX SDK and glew.h

#8 Post by mem359 »

adrian_broher wrote:
mem359 wrote:Which means the SDK won't work for me anyways, since the frameworks were compiled for i386 instead of x86_64.
Why is that?
I figured it would be easier to build the 64-bit libraries, but after snooping around, I guess I just need to find the right compiler flags to load the 32-bit libraries/Frameworks.

As you might guess, I know just enough about compilers to run them.
Modifying them is not second nature to me. (Yet.)

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: MacOSX SDK and glew.h

#9 Post by adrian_broher »

mem359 wrote:I guess I just need to find the right compiler flags to load the 32-bit libraries/Frameworks.
I doubt that. Just open the Xcode project files provided located inside the Xcode directory of the freeorion repository. Those are set up for building the project as we had this intended. Vezzra and our CI system use those for the weekly/per commit builds.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: MacOSX SDK and glew.h

#10 Post by Vezzra »

mem359 wrote:I just ran the bootstrap on a fresh copy, and looked more carefully at the log:
Unzipping dependencies...
tar: invalid option -- 'y'
Try `tar --help' or `tar --usage' for more information.
Done.
Removing archive...
I looked at the bootstrap file, and see this:

Code: Select all

echo 'Unzipping dependencies...'
tar -xyf dep.tar.bz2 -C Xcode
echo 'Done.'
echo 'Removing archive...'
Since "tar" does not have a "y" option, it looks like it failed to unpack the dep.tar.bz2 file, and then erased it anyways.
That's strange. I just ran "man tar" in my terminal, and here we go:

Code: Select all

...
     -y      (c mode only) Compress the resulting archive with bzip2(1).  In extract or list modes, this option is
             ignored.  Note that, unlike other tar implementations, this implementation recognizes bzip2 compression
             automatically when reading archives.
...
Apparently "-y" is an alias for "-j", because I have also this:

Code: Select all

...
     -j      (c mode only) Compress the resulting archive with bzip2(1).  In extract or list modes, this option is
             ignored.  Note that, unlike other tar implementations, this implementation recognizes bzip2 compression
             automatically when reading archives.
...
Which means the "tar" command should run. My only guess is, considering that I'm still on Yosemite and you're on El Capitan, that you've got a newer version of tar on your system which deprecated the "-y" option. To be sure I just did a test run with v4 of the OSX SDK on my system, and it worked flawlessly. No errors, "dep" got extracted just fine.

Of course, that does not explain why the "-y" option is specified here, after all it's going to be ignored for extraction anyway. Maybe specifying bzip2 compression was necessary back when this script originally has been written, or maybe I just thought it might be necessary and put it in just to be safe, and left it as it seemed to work. Just did another test where I removed the "-y" option (so only "-xf" has been left), and that worked flawlessly too, so I guess we can remove it.
(I just ran the tar file, which failed unless I used sudo before the tar -xf. All the missing headers and frameworks are in the now-created Xcode/dep folder.)
Sudoing should definitely not be necessary. Where did you copy the dep.tar.bzip2 and bootstrap.command files to? It needs to be a folder where you have unrestricted read/write access (so somewhere in your home directory).

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: MacOSX SDK and glew.h

#11 Post by Vezzra »

mem359 wrote:I figured it would be easier to build the 64-bit libraries, but after snooping around, I guess I just need to find the right compiler flags to load the 32-bit libraries/Frameworks.

As you might guess, I know just enough about compilers to run them.
Modifying them is not second nature to me. (Yet.)
I still don't understand. Why would you have to set specific compiler flags to load the 32bit libraries? The Xcode project is set up to produce a 32bit build of FO, so everything (libraries, frameworks, executables) is being build with 32bit. You should be able to use the SDK out-of-the-box. Copy the contents of the SDK .dmg file to an empty folder (where you have unrestricted read/write access), run bootstrap.command, open the FreeOrion.xcodeproj file in the Xcode folder and hit Command-B. Wait a while, if you get segfaults during the compile (happens now and then), just hit Command-B again, and that's it.

You don't need to enable anything 64bit anywhere, on the contrary, this will only screw things up. AFAIK, El Capitan is able to handle 32bit binaries just fine...

User avatar
mem359
Dyson Forest
Posts: 214
Joined: Sun Jun 08, 2014 1:18 am

Re: MacOSX SDK and glew.h

#12 Post by mem359 »

Vezzra wrote:...
Which means the "tar" command should run. My only guess is, considering that I'm still on Yosemite and you're on El Capitan, that you've got a newer version of tar on your system which deprecated the "-y" option. To be sure I just did a test run with v4 of the OSX SDK on my system, and it worked flawlessly. No errors, "dep" got extracted just fine.
...
:oops:
Thanks for the feedback. I had no idea (until now) that my Fink repository took over "tar".

Apparently, the Fink version

Code: Select all

tar (GNU tar) 1.26
does not have the -y option, while the normal system version

Code: Select all

bsdtar 2.8.3 - libarchive 2.8.3
is exactly what you describe.

What got me down the rabbit hole even further is that Linux doesn't have the y option either, so I figured that was normal.
( http://www.linuxcommand.org/man_pages/tar1.html )

As far as "sudo" goes, I'm guessing my work folder was created as "root", which meant I needed root privileges to unpack the tar file into it...
:twisted:

I'll do a clean sweep of my work area, reboot (so my laptop is not in some funny state), make sure the right "tar" is being used, then see if I still get strange behavior from the XCode build.

EDIT: In trying to fix the XCode compile (when I didn't have a "dep" folder due to the GNU tar), I had XCode update the settings to see if that would help. One of those "fixes" was to automatically pick the architectures, which meant 64-bit build, which meant problems with the SDK libraries. Trying to solve one problem, I created several more... Now that "tar" is straightened out, I won't mess with the XCode settings.
Last edited by mem359 on Thu Mar 02, 2017 2:02 pm, edited 1 time in total.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: MacOSX SDK and glew.h

#13 Post by Vezzra »

Ah yes, that clears up a lot. Well, on the plus side we learned that we can remove the "y" option (which apparently isn't universal standard). :)

User avatar
mem359
Dyson Forest
Posts: 214
Joined: Sun Jun 08, 2014 1:18 am

Re: MacOSX SDK and glew.h

#14 Post by mem359 »

Everything works like it should, now.
Can use my build, and the exe seems to be behaving like the weekly released test build.
Thanks for the help. Sorry for the confusion and the trip down the rabbit hole.

(This whole exercise was to put in a temporary fix for the load-game server time-out, so that I could play FO before the actual fix is implemented next week.)

Post Reply