Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GNU/kFreeBSD support #1093

Merged
merged 8 commits into from Jul 16, 2016

Conversation

Projects
None yet
5 participants
@stevenc99
Copy link
Contributor

commented Jul 13, 2016

Hi!

This series of patches fixes the current issues building mame on Debian GNU/kFreeBSD. There were some assumptions in code that glibc (its headers and functions) is not available when building on a BSD platform.

Thanks!

stevenc99 added some commits Jul 13, 2016

bx: use real alloca.h on glibc systems
On GNU/kFreeBSD, the definition for alloca() can be found in the
system alloca.h
bx: use system signal.h on glibc systems
On GNU/kFreeBSD, sys/signal.h is only a wrapper around glibc signal.h
anyway, leading to a #include loop in this case.
bx: support glibc-based BSD platforms
On GNU/kFreeBSD, pthread_setname_np can be found in glibc's pthread.h
(same as on GNU/Linux).  pthread_np.h does not exist there.
@balr0g

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2016

@stevenc99, thanks! Could you PR the bx changes upstream?

bx: refactor #ifdefs
Fix potential compilation error by ensuring __GLIBC__ is only evaluated
when actually defined.

When __GLIBC__ is defined, we do not need any additional headers on BSD
platforms (hence why using #elif).
@cuavas

This comment has been minimized.

Copy link
Member

commented Jul 13, 2016

After the changes does it still build on stock FreeBSD without the GNU environment? For example the change to src/osd/modules/file/posixptty.cpp - is that define present on stock FreeBSD?

bx: further refactor #ifdefs
Trying to evaluate __GLIBC__ will result in an error if is not defined,
if the preprocessor does not short-cut the evaluation.

Split the macros onto separate lines and define the result in a new
BX_USE_GLIBC_PTHREAD_SETNAME_NP macro to avoid duplication.
@stevenc99

This comment has been minimized.

Copy link
Contributor Author

commented Jul 13, 2016

Hi @cuavas: stock FreeBSD already defines FreeBSD_kernel, but I did not test building on a FreeBSD machine with these changes (I don't have any suitable build environment to do it myself).

@jmallach

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2016

Hi @cuavas! Yes, FreeBSD_kernel is available on regular FreeBSD:

https://svnweb.freebsd.org/base/head/sys/sys/param.h?view=markup#l64

@jmallach

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2016

This, of course, would fix #1044.

@stevenc99 stevenc99 referenced this pull request Jul 13, 2016

Closed

GNU/kFreeBSD support #119

@stevenc99

This comment has been minimized.

Copy link
Contributor Author

commented Jul 13, 2016

Sent a pull request to bx upstream bkaradzic/bx#119

@stevenc99 stevenc99 force-pushed the stevenc99:kfreebsd branch to ef8816a Jul 14, 2016

@stevenc99

This comment has been minimized.

Copy link
Contributor Author

commented Jul 15, 2016

@balr0g: the bx parts are merged upstream. Commit ef8816a pulled the relevant parts (but not all upstream changes) into this merge request. Thanks.

@rb6502 rb6502 merged commit 13c8e76 into mamedev:master Jul 16, 2016

2 checks passed

continuous-integration/tea the build was successful
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.