[FIXED]New XCode Upgrade causes compiling trouble

Archives Forums/BlitzMax Bug Reports/[FIXED]New XCode Upgrade causes compiling trouble

Tricky

(Posted 2015) [#1]

(See also this thread: http://www.blitzmax.com/Community/posts.php?topic=105027 )

Out of the blue without a proper warning Apple upgraded my XCode to a new version. As a result some serious compilation/linking issues pop up.

When compiling an application the linker will produce warnings about version conflicts, as the app being build for OSX 10.10 but linking for 10.4

Building Kthura Map Editor
Reading data from: /Volumes/Irravonia/Projects/BlitzMax/JCR6+/Kthura Map Editor/Kthura Map Editor.bmx.macicons
Using icon file: /Volumes/Irravonia/Projects/BlitzMax/JCR6+/Kthura Map Editor/Icons/Kthura.icns
Compiling:Kthura_Core.bmx
Compiling:Kthura_Draw.bmx
Compiling:Kthura_Save.bmx
Compiling:Kthura Map Editor.bmx
Linking:Kthura Map Editor.debug
ld: warning: object file (/Volumes/Irravonia/Projects/BlitzMax/JCR6+/Kthura Map Editor/.bmx/Kthura Map Editor.bmx.gui.debug.macos.x86.o) was built for newer OSX version (10.10) than being linked (10.4)
ld: warning: object file (/Volumes/Irravonia/Projects/BlitzMax/JCR6+/Kthura Map Editor/Mods/.bmx/Kthura_Save.bmx.debug.macos.x86.o) was built for newer OSX version (10.10) than being linked (10.4)
ld: warning: object file (/Volumes/Irravonia/Projects/BlitzMax/JCR6+/Kthura Map Editor/Mods/.bmx/Kthura_Draw.bmx.debug.macos.x86.o) was built for newer OSX version (10.10) than being linked (10.4)
ld: warning: object file (/Volumes/Irravonia/Projects/BlitzMax/JCR6+/Kthura Map Editor/Mods/.bmx/Kthura_Core.bmx.debug.macos.x86.o) was built for newer OSX version (10.10) than being linked (10.4)
Executing:Kthura Map Editor.debug

The app I was building here worked, by the way, though I don't know if it's compatible with older OS X versions.

Rebuilding all modules has become impossible resulting the compiler to throw an error:

Compiling:blitz_gc_rc.c
Compiling:blitz_ex.macos.x86.s
/Applications/BlitzMax/mod/brl.mod/blitz.mod/blitz_ex.macos.x86.s:9:7: error: unexpected token at start of statement
#   ;0[esp]=our ret
      ^
/Applications/BlitzMax/mod/brl.mod/blitz.mod/blitz_ex.macos.x86.s:10:7: error: unexpected token at start of statement
#   ;4[esp]=offset arg

Now I'm a total nitwit when it comes down to assembly (as the bug appears to be in assembly), so I don't know what to do to fix this. I guess this is only a small fix, but one that is needed. (I guess Apple has a very keen eye to getting BlitzMax to malfunction).

skidracer

(Posted 2015) [#2]

Upgrading XCode now. That error looks a bit off given those lines are comments not code.

Hmm.

to compile blitz_ex.macos.x86.s i removed all semi colons and tweaked the style of the jmp instruction


    .globl  _bbArgp
	.globl	__bbExEnter
	.globl	__bbExThrow

	.text

_bbArgp:

#	0[esp]=our ret
#	4[esp]=offset arg
#	0[ebp]=caller oldebp
#	4[ebp]=caller ret
#	8[ebp]=caller first arg!
	lea		8(%ebp),%eax
    add     4(%esp),%eax
	ret

#	0[esp]=ret
#	4[esp]=state block
__bbExEnter:
	mov		4(%esp),%edx
#	
	mov		%ebx,(%edx)
	mov		%esi,4(%edx)
	mov		%edi,8(%edx)
	mov		%ebp,12(%edx)
#	
	mov		(%esp),%ecx
	mov		%esp,16(%edx)
	mov		%ecx,20(%edx)
#	
	xor		%eax,%eax
	ret

#	0[esp]=ret
#	4[esp]=state block
#	8[esp]=throw value
__bbExThrow:
	mov		4(%esp),%edx
	mov		8(%esp),%eax
#	
	mov		12(%edx),%ebp
	mov		8(%edx),%edi
	mov		4(%edx),%esi
	mov		(%edx),%ebx
#	
	mov		20(%edx),%ecx
	mov		16(%edx),%esp
	add		$4,%esp
	jmp		*%ecx

for blitz_ftoi.maxos.x86.s i just removed semicolons


	.globl	_bbFloatToInt

	.text

#	0[esp]=ret
#	4[esp]=double
_bbFloatToInt:
	fldl	4(%esp)
	sub	$12,%esp
	fistl	(%esp)
	fsts	4(%esp)
	fisubl	(%esp)
	fstps	8(%esp)
	pop	%eax
	pop	%ecx
	pop	%edx
	test	%ecx,%ecx
	js	negative
	add	$0x7fffffff,%edx
	sbb	$0,%eax
	ret
negative:
	xor	%ecx,%ecx
	test	%edx,%edx
	setg	%cl
	add	%ecx,%eax
	ret

But now I am completely stuck on call %eax in some bmx generated reflection code.

The answer maybe to get bmk to call assembler with intel setting style enabled.

This new clang-based assembler in Xcode 7 sure is odd...

AdamStrange

(Posted 2015) [#3]

@skidracer
You're the man. Modified and came to the same halt over the CALL command

Burcey??

skidracer

(Posted 2015) [#4]

As bcc is still closed source Brucey can't help patch this one.

AdamStrange

(Posted 2015) [#5]

Bugger :/ So I'm assuming that bcc is the issue now.

Oh Mark...

I did do some research and found that there have been a number of other with similar errors, but nothing directly relating to "call"

I'm a bit rusty with assembler (and not done any on the mac). but if there's anything I can attempt to help with then Mark only has to ask :)

Tricky

(Posted 2015) [#6]

At least I'm glad action is being taken :) (As my current project is suffering, and I'd hate to have to cancel it due to these problems).
By the way, I've been experimenting in Free Pascal lately where the same issue pops up in linking a program. I guess there's a lot Apple did in XCode without a warming causing other compilers to suffer.

*	(Posted 2015) [#7]

I think it's one of the reasons Apple is still niche compared to windows (on market share) due to Apples insistence on changing, breaking and retiring stuff.

Tricky

(Posted 2015) [#8]

" due to Apples insistence on changing, breaking and retiring stuff. "

It's indeed not helping. Now I am doing this in my free time in an open-source project. If I had invested money in this project, or would have been funded by kickstarter or anything like that I would be even less amused (to put it mildly) by this stunt of Apple's. (And I highly doubt BlitzMax and FreePascal are the only tools suffering here). Being nice to the developers will certainly help to get OS X to become a greater system (if Apple even CARES about that).

John G

(Posted 2015) [#9]

I believe Apple's priority long ago switched from OSX to iOS.

Tricky

(Posted 2015) [#10]

It's still the same XCode they keep changing causing compatibility issues, so I don't think iOS is better of than OSX on this one.

Brucey

(Posted 2015) [#11]

But now I am completely stuck on call %eax in some bmx generated reflection code.

Maybe it needs an asterisk in front?... call *%eax

skidracer

(Posted 2015) [#12]

Yup. I was trying that when I realised bcc was regenerating file each time and MaxIDE is too stoopid to know when a file has been modified on disk....

Anyways, I'm just glad I have two Macs, one uninfected with Xcode 7 (and access to bcc source) so I will be having another crack this weekend and maybe poke Mark for a comment.

Tricky

(Posted 2015) [#13]

Anyways, I'm just glad I have two Macs

Uh, yeah, two macs. I just realized I have two macs too. My Mac Mini is now taken over by XCode 7, but my iMac is not (it's even still on Mountain Lion). It suffers from ghosting though, but that's not really an issue when compiling blitz source is it?

MaxIDE is too stoopid to know when a file has been modified on disk....

Yeah, something I really hate to face, after I've been using Eclipse to modify my Lua scripts (and Eclipse is not that "stoopid") and an update to my Blitz Code is needed.

xlsior

(Posted 2015) [#14]

As bcc is still closed source Brucey can't help patch this one.

Doesn't Brucey's bcc-ng replace the stock bcc altogether?

AdamStrange

(Posted 2015) [#15]

I'm just in the process of removing Xcode 7 and replacing with older version :(

OK. Brucey. You need help with NG on mac - I'm now up for it :)

AdamStrange

(Posted 2015) [#16]

I've also got some ideas about how we could write a new idea with profiling

Brucey

(Posted 2015) [#17]

I'm just in the process of removing Xcode 7 and replacing with older version

I haven't updated yet. I thought it's better to hang on until I really need to - it also means not updating iOS to 9 - as it requires XCode 7 to build for it... meh.

a new idea with profiling

There's some fantastic profiling built into OS X dev tools. I've already used it to analyse a game and find some places where code can be drastically improved. (I've also used profilers on OS X and Linux to help improve bcc's generated code).

You need help with NG on mac - I'm now up for it

As long as you use pointers for pointers (and not Ints, like Mark and Skid did) then generally there's not much to tweak. (SuperStrict) BlitzMax source itself generally shouldn't require any changes to work with NG's bcc.

AdamStrange

(Posted 2015) [#18]

No problem there. I've got no pointers - hmmm, strike that. I do use them in some audio stuff, but I can take that as needed.

Is there a nice a simple step by step guide for installing NG?

Brucey

(Posted 2015) [#19]

Is there a nice a simple step by step guide for installing NG?

There probably wants to be...

For now, this should get you started :

Create a folder with the following folders :

new_blitzmax_folder/
  bin/
  mod/
  src/

From https://github.com/bmx-ng , download bcc and bmk into src/, and pub.mod and brl.mod into mod/
Unzip and rename appropriately.

Using your official BlitzMax, build src/bcc and src/bmk. (console, not GUI)
You'll have a nicer experience if you build bmk with threading enabled.

Copy bcc and bmk binaries, along with core.bmk and make.bmk (from src/bmk) into bin/.

Open a terminal into bin/

A quick version will tell you if the binaries are good :

$ ./bcc -v
bcc[ng] Release Version 0.62

$ ./bmk -v
bmk 3.06 mt-macos-x86 / clang 602.0.53 (cpu x4)

And then you can build :

./bmk makemods -a

Now you have a default (as far as modules are concerned), working NG.

Tricky

(Posted 2015) [#20]

Uhm.... question. I did compile bcc and bmk and placed everything in bin as said I should do. Then I placed the modules into the respective mod directory.
Right compiling bcc and bmk "worked" (though the version conflicts this thread is originally about) did occur. And when I fired bmk up to compile all modules.... nothing happened.

Brucey

(Posted 2015) [#21]

@Tricky
This wasn't intended as a solution to your problem, just a reply to AdamStrange's request for information.

However, in answer to your comment...

And when I fired bmk up to compile all modules.... nothing happened.

Firstly, you should do the version test, as above, which will show the binaries will run (at all).

Then double check the names of the folders in your mod/ dir.

I expect everything to *just* work, assuming your binaries built okay, although I have yet to upgrade to XCode 7 myself, so there may be some issue that I am unaware of.

Tricky

(Posted 2015) [#22]

The "bmk -v" and "bcc -v" commands return the results you stated above. And running "bmk" without any parameters at all, will show me the overview of all options bmk can be run with. And I know this wasn't a solution to my problem but I was already considering to give your stuff a try. I deem it very well possible XCode 7 is in the way (and I wonder what I can do to downgrade to XCode 6, as Apple is not very informative on that one).

skidracer

(Posted 2015) [#23]

Perhaps just delete xcode 7 and download 6.4 from here

https://developer.apple.com/downloads/

Tricky

(Posted 2015) [#24]

And how do I "just delete xcode 7"? I can't find where it is installed and when I google on how to do it nothing is found (all I find handles older Xcode versions and the methods do not work on 7). I already have downloaded 6.4. It's even installed already, however XCode 7 steals the priority and both BlitzMax and FreePascal ignore 6.4's existence as a result and I don't know what to do to get past that.

(Oh would deleting XCode.app in my applications folder really be enough?)

skidracer

(Posted 2015) [#25]

Yes, Although renaming xcode.app as xode7.app should work equally well.

As for googling, the xcode-select command I think is still valid for selecting a particular toolchain.

Tricky

(Posted 2015) [#26]

Right, downgrading XCode succesful and BlitzMax appears to be working on me again (at least the modules were compiling without the errors mentioned above, so I suppose that's a good sign), so I'm saved for now. Though I think some stuff needs to be done on BlitzMax as I guess XC7 will be the standard for El Capitan.
Thank you for helping me out, skid. I hope you guys nail the problem quickly. :)

@Brucey
I tried to recompile your compiler now that I succesfully downgraded to XC6.4 and rebuilding the modules still does nothing at all. Not even an error notice or anything. I just immediately get the unix command prompt again.
[EDIT] I found the problem. Make.bmk was not properly copied to bin. Silly me. Now that it *is* properly copied, it works.

AdamStrange

(Posted 2015) [#27]

ok, I'm just at 23% and not a good head for heights today, so I'll take things nice n slow...

marksibly_v2

(Posted 2015) [#28]

Hi,

Please try v151 from the product updates section.

AdamStrange

(Posted 2015) [#29]

Nice one Mark.

Just down loading and modifying some of the core mods too keep track with mine :)

Tricky

(Posted 2015) [#30]

Hey, cool! Thanks, Mark!

Tricky

(Posted 2015) [#31]

Right, I was also waiting for switching back to XC7 until I heard some news from the guys from FreePascal, and according to them FPC should be safely usable, so I may try everything out tomorrow (it would be annoying to have to use XC7 for BMax and XC6 for FPC you see).

One question though, the confusing warnings ld showed, imply stuff as "being compiled for 10.10" and stuff. Does this mean that the stuff I compile in 1.51 require OSX 10.10 (Yosemite) or will they still work in older OS X versions as well? (I'm asking as I want my future users to be properly informed about the system requirements)

Floyd

(Posted 2015) [#32]

From versions.txt, as quoted in the other XCode thread

Builds on Snow Leopard or later will now produce apps for Snow Leopard or later. To build apps for pre-Snow Leopard, you MUST use a
pre-Snow Leopard OS to build on.

Tricky

(Posted 2015) [#33]

Yeah, soon after I posted that I found that one myself, but time pressure prevented me from editing my post as being "answered", but thanks anyway ;)