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

Makefile interoperability updates #19

Merged
merged 1 commit into from
Jan 8, 2018
Merged

Conversation

MartB
Copy link
Contributor

@MartB MartB commented Jun 29, 2017

Removed unnecessary arch detection which broke builds on other platforms e.g AARCH64
Removed hardcoded gcc compiler setting as its not required, clang works just as fine

I tried to find a reason for this but found none should be safe on all systems.
(Tested on aarch64, x86_64)

Removed unnecessary arch detection which broke builds on other platforms e.g AARCH64
Removed hardcoded gcc compiler setting as its not required, clang works just as fine
CFLAGS=-fPIC -O3 -fomit-frame-pointer -fno-exceptions -Wall -std=c99 -pedantic
ifeq (${PROC},x86_64)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this may be needed if 32bit code is compiled on x86_64 machines, so I'm not confortable in turning it off.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It breaks compilation on 64BIT arm architectures.

If people really need that they can specify it in the make commandline.
make CFLAGS=-m32

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know at least some users that use it in automated build systems, so this is not really a good option. (don't like to expose CFLAGS to the normal user)

The best way is to adapt the Makefile to do proper discovery, maybe using uname -i ?
I don't have an x86_64 arm to test right now (maybe later)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to separate between 32 and 64 we could use getconf LONG_BIT this should return 64 or 32 based on the host OS architecture.
But lets think about what we are doing to the CFLAGS here, basically we are only specifying options for 64bit systems that are already set if you use a 64bit compiler. For 32bit systems we force the arch to i686 but why do we do that ? Whats the reasoning behind this ?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, agreed about the i686 arch (basically I never thought about arm or others).
the important part here is the m32 flag that generates 32bit code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds about right, as far as i know you cant really crosscompile on arm anyway.
x86_64 and x86 are indeed the most prominent example of natively working crosscompilation.

Copy link
Contributor Author

@MartB MartB Jul 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay was busy last week will give this a shot in a few days/weeks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And i never did, sorry for that!
I dont know whats the best way to do this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, i think this entire thing is not needed and can be dropped.
Reasons:

  1. GCC automatically defaults to 32bit if the installed compiler is 32bit (like it is by default on a 32bit machine with an x64 cpu)
  2. It only causes problem for other architectures.
  3. 32bit linux is going to die soon enough Ubuntu 17.10 already dropped support.
  4. I could not find a valid use-case for this code (tried a 32bit vm with an x64 cpu)

I suggest accepting this merge request in its current and original state.
If you can provide me with a solid proof that the code is actually needed i will figure out additional options.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, granted :) going to merge as is.

@xadhoom xadhoom merged commit 5d28a25 into xadhoom:master Jan 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants