LiveCode Forums.

Posted: **Fri Apr 12, 2013 4:37 pm**

Plugging on, compiling the source on 64-bit linux mint everything was going fine until I ran into the following.
So... would it be safe to change the typedefs in core.h?

(I didn't actually realize you could say "long long int" without the compiler barfing)

In file included from ./src/core.cpp:16:0:
./../libcore/include/core.h:214:55: error: ‘operator new’ takes type ‘size_t’ (‘long unsigned int’) as first parameter [-fpermissive]
In file included from /usr/include/string.h:34:0,
from /usr/include/c++/4.7/cstring:44,
from ./src/core.cpp:18:
/usr/lib/gcc/x86_64-linux-gnu/4.7/include/stddef.h:213:23: error: conflicting declaration ‘typedef long unsigned int size_t’
In file included from ./src/core.cpp:16:0:
./../libcore/include/core.h:45:22: error: ‘size_t’ has a previous declaration as ‘typedef unsigned int size_t’
In file included from /usr/include/stdlib.h:320:0,
from /usr/include/c++/4.7/cstdlib:66,
from ./src/core.cpp:19:
/usr/include/x86_64-linux-gnu/sys/types.h:198:1: error: conflicting declaration ‘typedef long int int64_t’
In file included from ./src/core.cpp:16:0:
./../libcore/include/core.h:34:26: error: ‘int64_t’ has a previous declaration as ‘typedef long long int int64_t’
In file included from ./src/core.cpp:146:0:
/usr/include/unistd.h:268:20: error: conflicting declaration ‘typedef __intptr_t intptr_t’
In file included from ./src/core.cpp:16:0:
./../libcore/include/core.h:60:17: error: ‘intptr_t’ has a previous declaration as ‘typedef int64_t intptr_t’
make[1]: *** [../_cache/linux/debug/libcore/core.o] Error 1
make[1]: Leaving directory `/home/mwieder/Revolution/versions/livecode/libcore'
make: *** [libcore] Error 2

Posted: **Fri Apr 12, 2013 5:02 pm**

Mileage might vary with an attempt at a 64-bit compiler...

I believe Linux uses the LP64 model, which means 'long' ints and pointers are 64-bit, whereas ints are 32-bit.

Hopefully the compiler will predefine something to indicate it is LP64 - the Apple ones define __LP64__ - and you could use this to add in appropriate ifdefs to the core.h header.

The sources of evil you are experiencing here seem to be the typedef of size_t, uint64_t and int64_t. You might find that just ensuring the following is typedef'd will make everything compile:
typedef long unsigned int size_t;
typedef long unsigned int uint64_t;
typedef long int int64_t;

I'm not sure of the ramifications of compiling under 64-bit as there might well be code that isn't 64-bit clean - in particular, places using 'long' as a type rather than a fixed size int (such as int32_t or int64_t) might cause problems. That being said, at some point in the past I did get the Mac server engine building for 64-bit so you might want to start there and aim for that working initially.

Posted: **Fri Apr 12, 2013 5:08 pm**

Thanks. I don't have a problem finding and changing the typedefs. Just wondering whether there are legacy issues that explain why the 32-bit typedefs are still in place.
I'll give it a try.

Posted: **Fri Apr 12, 2013 5:12 pm**

The reason for core.h containing all the necessary typedefs is to ensure the code compiles on all platforms without having to mess around heavily with C library headers. Whilst C is 'standardized' there's still enough platform-dependent parts of it, and variance amongst compilers to mean it can be a complete headache.

Posted: **Fri Apr 12, 2013 5:44 pm**

Yes, but my question is... if I change the typedefs to be 64-bit compliant, do I run the risk of breaking legacy 32-bit code in the engine? Do I have to #ifdef them to be safe?

Posted: **Fri Apr 12, 2013 5:53 pm**

Yes - you need to ifdef based on whether the compiler is 64-bit. The current definitions work for the 32-bit linux compilers, but the ones needed for 64-bit might not.

Posted: **Fri Apr 12, 2013 7:51 pm**

I follow this thread with great interest. Would love to see a linux 64 bit version.

Posted: **Sat Apr 13, 2013 6:49 am**

I think I'm most of the way to getting a valid 64-bit compile now. Little by little.

I had to #ifdef the uint64_t support in both engine/src/typedefs.h and libcore/include/core.h (why is this typedef'd in two places?

Code: Select all

#if !defined(uint64_t)
	typedef unsigned long int uint64_t;
#endif
#if !defined(int64_t)
	typedef signed long int int64_t;
#endif

#ifndef _UINTPTR_T
	#define _UINTPTR_T
	#ifdef __LP64__
		typedef uint64_t uintptr_t;
	#else
		typedef uint32_t uintptr_t;
	#endif
#endif

#ifndef _INTPTR_T
	#define _INTPTR_T
	#ifdef __LP64__
		typedef int64_t intptr_t;
	#else
		typedef int32_t intptr_t;
	#endif
#endif

I had to #ifdef my way around definitions for Window, Pixmap, and Drawable in engine/src/sysdefs.h
I changed the #ifndef in line 706 of sysdefs.h to #ifdef because I think it's wrong.

Code: Select all

#else

	// {MDW} 2013.04.12 changed this from #ifndef
	#ifdef __LP64__
		#if !defined(Window)
			typedef unsigned long Window;
		#endif
		#if !defined(Pixmap)
			typedef unsigned long Pixmap;
		#endif
		#if !defined(Drawable)
			typedef unsigned long Drawable;
		#endif
	#else
		#if !defined(Window)
			typedef unsigned int Window;
		#endif
		#if !defined(Pixmap)
			typedef unsigned int Pixmap;
		#endif
		#if !defined(Drawable)
			typedef unsigned int Drawable;
		#endif
	#endif

#endif

I had to install libxft-dev
I had to install libxcb-image0-dev, but this may not have been necessary because
I had to insall libxv-dev
I had to install Xinerama

Lots of warnings - it'll take some time to get around those.
I had to cast (int32)buffer == -1 into (void*)buffer == (void*)-1 in engine/src/lnxspec.cpp. I hate doing that.
I had to install libxcursor-dev

...and now I'm up against

./src/fieldstyledtext.cpp: In member function ‘void MCField::parsestyledtextappendblock(MCParagraph*, MCVariableValue*, const char*, const char*, const char*, bool)’:
./src/fieldstyledtext.cpp:430:76: error: call of overloaded ‘MCMin(long int, int)’ is ambiguous
./src/fieldstyledtext.cpp:430:76: note: candidates are:
In file included from ./src/fieldstyledtext.cpp:19:0:
./../libcore/include/core.h:473:17: note: uint32_t MCMin(uint32_t, uint32_t)
./../libcore/include/core.h:475:16: note: int32_t MCMin(int32_t, int32_t)
./../libcore/include/core.h:477:16: note: int64_t MCMin(int64_t, int64_t)
./../libcore/include/core.h:479:16: note: int64_t MCMin(uint64_t, uint64_t)
./../libcore/include/core.h:481:15: note: double MCMin(double, double)
./../libcore/include/core.h:483:14: note: float MCMin(float, float)

Posted: **Sat Apr 13, 2013 7:06 am**

Okay - I faked my way past that by casting the arguments to (int64_t).
That'll do for the moment.
Now I think I've created some kind of a FrankenEngine. I'm going to have to go over the compiler options...

Code: Select all

gcc -fvisibility=hidden -o./../_build/linux/debug/standalone -static-libgcc -Wl,--script=standalone.link -Wl,-rpath,\$ORIGIN -L./../prebuilt/lib -Xlinker -no-undefined -Xlinker --exclude-libs -Xlinker libstdc++.a ./../_cache/linux/debug/standalone/lextable.o ./../_cache/linux/debug/standalone/mode_standalone.o   \
			-Wl,-Bstatic \
			-Wl,--start-group \
				./../_build/linux/debug/libkernel.a ./../_build/linux/debug/libcore.a ./../_build/linux/debug/libz.a ./../_build/linux/debug/libgif.a ./../_build/linux/debug/libpng.a ./../_build/linux/debug/libpcre.a ./../_build/linux/debug/libjpeg.a ./../_build/linux/debug/libopenssl.a \
				-lstdc++ \
			-Wl,--end-group \
			-Wl,-Bdynamic \
			 \
			-ldl -lX11 -lm -lXext -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status

Posted: **Sat Apr 13, 2013 7:38 am**

OMG. It compiled.

Code: Select all

ldd engine
	linux-vdso.so.1 =>  (0x00007fffd1c9e000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff76ad41000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007ff76aa07000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff76a70a000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007ff76a4f8000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff76a2db000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff769f1b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ff76af64000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007ff769cfd000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007ff769af9000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007ff7698f2000)

Posted: **Sat Apr 13, 2013 8:46 am**

It's such a surprise when it finally does that

Good work! This is desktop not server right?

Posted: **Sat Apr 13, 2013 2:39 pm**

I'm guessing its desktop, given the need for Xinerama etc.

This sounds like good progress... Of course, the question is, how well does it work?

Posted: **Sat Apr 13, 2013 7:19 pm**

Yes, that's definitely the question. Are there acceptance tests set up? Are you using one of github's Travis instances as a CI server?
I got as far as getting the registration screen and then went to bed.
At this point I'd rather strip out or bypass the registration stuff than continue with it as is, but I'll make a branch for that.

I pulled the 6.0.1 branch and it merged with no conflicts, so I guess my next step will be to push to my github fork, pull the changes to my 32-bit VM, and make sure it still compiles there. If that works then I'll submit a pull request

Posted: **Sat Apr 13, 2013 7:25 pm**

My guess is also that it's desktop. It runs on the desktop.
It's what got built in livecode/_build/linux/debug after running a "make all".
That's my story and I'm sticking to it.

Posted: **Sat Apr 13, 2013 11:05 pm**

That's my story and I'm sticking to it.

It's a good story

Would be good to see a 64 bit server version but I guess if desktop compiles then server is highly likely to also...

At this point I'd rather strip out or bypass the registration stuff than continue with it as is, but I'll make a branch for that.

Hmm... once you register it won't show that again or are you taking an ideological stand against it? I definitely think the stack should be modified to allow skipping this step and then make the services like revOnline and other content more compelling so people want to login... but as I said on the use list I'm glad I'm not in charge of these decisions and I won't be making a fork that removes this because I've got more interesting things to do...

LiveCode Forums.

the dreaded 64-bit compile

the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile

Re: the dreaded 64-bit compile