the dreaded 64-bit compile

[mwieder]

On my linux mint system I have libcurl3 installed but not libcurl4. I'm pretty sure I didn't install libcurl as part of the process of getting the engine to compile, so it would have come already installed with the OS. What I see installed is

libcurl3-gnutls 7.27.0-1ubuntu1.1
libcurl3-nss 7.27.0-1ubuntu1.1
libcurl3:i386 7.27.0-1ubuntu1.1

plus a couple of python libraries:
python-pycurl 7.19.0-5ubuntu1
pythun3-pycurl 7.19.0-5ubuntu1

I'll check my Fedora system when I get to work tomorrow and see what's there.

[monte]

hmm... I have libcurl 7.27.0 too... the headers in thirdparty are from 7.21.1

[LCMark]

Building a linux binary on one distribution in no way guarantees it will run on another. For example, if you compile the engine against libcurl4 then it won't run on a system that only has libcurl3. On server this problem is particularly important to avoid since many hosting providers don't tend to like installing extra libraries to support user installed binaries; thus we ensure that the Linux server builds are statically linked to all but the standard c library meaning they will run on just about any system.

The reason the server build is encountering problems at the moment is that we haven't included the necessary precompiled libraries in prebuilt - when that is done, it should compile without problem.

[monte]

Hmm... Now that its open source though we can build it on the machine we want to run it on.

[LCMark]

Yes... You can - because you have the engine source-tree and are happy to do so.

However, there will be many people who will just want to download a binary and use that; also the source-tree is used to build the commercial edition as well where people don't have the option to compile it themselves for their specific platform.

[ The case of standalone engines actually makes this situation clearer - if the standalone engine only ran on specific distros, you'd have to build a standalone for each different linux distro when you release your app... I'm not sure this is something anyone would want to have to do given how many they might need. ]

Linux has always been a bit of a problem for closed-source applications in regard to binary compatibility - and due to us being dual-licensed this situation doesn't really change. That being said, my long term wish has been that we move the engine to build against the Linux Standards Base 'sdk' which would be a less ad-hoc solution to the way we currently do things (although the LSB only covers certain libraries, so it only provides an improvement, rather than a complete solution).

[monte]

I was thinking specifically about server when I said that. Given most use cases for server would use the GPL version it might be good to have that option.

[mwieder]

Re: curl...

Now that I'm back at my 32-bit machine, I see that I'm able to compile the desktop engine without a problem, but I run into the same (I think) problems as Monte. The server needs some libraries that are not installed by default, and I get the following errors trying to build the server:

Code: Select all

/usr/bin/ld: cannot find -lcurl
/usr/bin/ld: cannot find -lssl
/usr/bin/ld: cannot find -lcrypto
/usr/bin/ld: cannot find -lrt

Since this is now server-related and not 64-bit related, I've started a new topic at http://forums.runrev.com/viewtopic.php?f=66&t=14759

[mwieder]

Running gdb I can see that my 64-bit compiled engine is failing after my login attempt at stroke in pathprocess.cpp, which is not at all where I expected to end up.

[LCMark]

What backtrace are you getting when it crashes?

By the way, I'll see if we can integrate the initial 64-bit changes you've figured out for 6.0.1 - no need to submit a pull request necessarily, I can pull them in as needed from your branch. Hopefully this should help the march towards 'the dreaded' 64-bit

[mwieder]

Ah... don't pull them yet. I've got a couple of bugfixes to push and I won't be able to do that for another four hours.

[LCMark]

Lol - no rush - it's nearly 10pm here... No code integration happening here until tomorrow!

[mwieder]

Whew!

Filler:
Your message contains 5 characters. The minimum number of characters you need to enter is 10.

[mwieder]

OK - I submitted my pull request. Actually the 64-bit version is moving right along. Had trouble opening plugins, so I disabled the user plugins folder (renamed it) and it loads a functional revmenubar, tool palette, application bar. When you start to do things is where you run into trouble.

Creating a new mainstack worked fine.
Dragging a button from the tool palette worked until I dropped it on the stack.
The it segfaulted.
Program received signal SIGSEGV, Segmentation fault.
0x000000000056cf46 in stroke (
p_commands=0x202020106d1037c <Address 0x202020106d1037c out of bounds>,
p_data=0x18006d10005, p_stroke=0x6f08920, r_cache=...)
at ./src/pathprocess.cpp:568
568 if ((*t_command == PATH_COMMAND_END || *t_command == PATH_COMMAND_MOVE_TO) && t_first_angle.isset)

I've noticed that the stroke() function segfaults with the same problem (p_commands out of bounds). Need to spend some more time looking at stack traces with gdb.

But it's progress.

[mwieder]

Given that I won't be back to my 64-bit system for a few hours, I'll post a patch that I think fixes the segfault: in path.cpp, change the following two methods:

Code: Select all

void MCPath::release(void)
{
	if (this == NULL)
		return;

	f_references -= 1;
	if (f_references == 0)
	{
		// MDW-2013-04-17: data storage is now separate from MCPath object
		// so don't forget to free it as well.
		if (this -> f_commands != NULL)
			free(this -> f_commands);
		if (this -> f_data != NULL)
			free(this -> f_data);
		free(this);
	}
}

MCPath *MCPath::allocate(uint4 p_command_count, uint4 p_point_count)
{
	MCPath *t_path;

	// MDW-2013-04-17: eliminating magic numbers, adjusting for 64-bit space
	t_path = new MCPath;
	t_path -> f_references = 1;

	// pointer to a single byte that contains the commands
	t_path -> f_commands = (uint1*)malloc(sizeof(int));
	// point to the data space: each point is two ints
	t_path -> f_data = (int4*)malloc(p_point_count * 2 * sizeof(int));
	return t_path;
}

These work on my 32-bit system and I'll test and do a pull request later on.

[mwieder]

I just had a chance to test those latest changes.


It worked.

I now have a working 64-bit desktop engine. Given what Mark said earlier (not to mention the fact that I can't build the standalone engine yet), I'm reasonably sure that I can't build standalones, but it's a start.