FreeOrion

Forums for the FreeOrion project
It is currently Sat Nov 18, 2017 9:26 pm

All times are UTC




Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject: MacOSX SDK and glew.h
PostPosted: Wed Mar 01, 2017 6:53 pm 
Offline
Dyson Forest
User avatar

Joined: Sun Jun 08, 2014 1:18 am
Posts: 214
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#Software_requirements, 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).


Top
 Profile  
 
PostPosted: Wed Mar 01, 2017 7:33 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
I don't know what you have done exactly, but

Quote:
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.

Quote:
Should it have been part of the SDK?


It is part of the SDK.

Quote:
I can copy it by hand from the GLEW area on my computer, I suppose.


You should not.

Quote:
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


Top
 Profile  
 
PostPosted: Wed Mar 01, 2017 8:50 pm 
Offline
Dyson Forest
User avatar

Joined: Sun Jun 08, 2014 1:18 am
Posts: 214
adrian_broher wrote:
Quote:
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:
Quote:
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:
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


Top
 Profile  
 
PostPosted: Wed Mar 01, 2017 9:21 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4241
Location: Sol III
@mem359, which version of OSX are you running on?


Top
 Profile  
 
PostPosted: Wed Mar 01, 2017 10:08 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
@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


Top
 Profile  
 
PostPosted: Wed Mar 01, 2017 10:18 pm 
Offline
Dyson Forest
User avatar

Joined: Sun Jun 08, 2014 1:18 am
Posts: 214
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.)


Top
 Profile  
 
PostPosted: Wed Mar 01, 2017 10:19 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
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


Top
 Profile  
 
PostPosted: Wed Mar 01, 2017 10:48 pm 
Offline
Dyson Forest
User avatar

Joined: Sun Jun 08, 2014 1:18 am
Posts: 214
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.)


Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 7:10 am 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1040
Location: Germany
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


Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 9:37 am 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4241
Location: Sol III
mem359 wrote:
I just ran the bootstrap on a fresh copy, and looked more carefully at the log:
Quote:
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:
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:
...
     -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:
...
     -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.
Quote:
(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).


Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 9:51 am 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4241
Location: Sol III
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...


Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 1:23 pm 
Offline
Dyson Forest
User avatar

Joined: Sun Jun 08, 2014 1:18 am
Posts: 214
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:
tar (GNU tar) 1.26

does not have the -y option, while the normal system version
Code:
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.

Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 1:31 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4241
Location: Sol III
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). :)


Top
 Profile  
 
PostPosted: Thu Mar 02, 2017 2:35 pm 
Offline
Dyson Forest
User avatar

Joined: Sun Jun 08, 2014 1:18 am
Posts: 214
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.)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group