Skip to content

Pass the $(CC) variable to the configurator executable when building config.h - #1035

Merged
rustyrussell merged 1 commit into
ElementsProject:masterfrom
icota:master
Feb 20, 2018
Merged

Pass the $(CC) variable to the configurator executable when building config.h#1035
rustyrussell merged 1 commit into
ElementsProject:masterfrom
icota:master

Conversation

@icota

@icota icota commented Feb 19, 2018

Copy link
Copy Markdown
Contributor

When cross compiling it's important that the resulting config.h reflects the platform we are building for and not the one we are building on. Otherwise we end up with a config.h that defines headers that are not there on the target platform, wrong endianness and so on.

The -static flag is there to be able to easily run the configurator test executables on the build machine with qemu-*.

E.g. Without the -static flag the resulting dynamically linked ARM executables complain about the lack of linker (/lib/ld-linux-armhf.so or /system/bin/linker for Android), since these files are not usually available on the build machine building statically avoids this problem and results in a proper config.h for cross compiling.

Related to #653

…ng ccan/config.h

When cross compiling it's important that the resulting config.h reflects the platform we are building for and not the one we are building on.
Otherwise we end up with a config.h that defines headers that are not there on the target platform, wrong endnianness and so on.
The -static flag is there to be able to easily run the configurator test executables on the build machine with qemu-*.
E.g. Without the -static flag the resulting dynamically linked ARM executables complain about the lack of linker (/lib/ld-linux-armhf.so or /system/bin/linker for Android), since these files are not usually available on the build machine building statically avoids this problem and results in a proper config.h for cross compiling.
@ZmnSCPxj

Copy link
Copy Markdown
Contributor

Would ACK, but do not know enough about target device to judge well.

I am concerned about the forced use of -static in all cases however, would it not affect also builds on Linux x86 and x86-64?

@icota

icota commented Feb 19, 2018

Copy link
Copy Markdown
Contributor Author

@ZmnSCPxj I am concerned as well. Tests inside configurator.c seemed to be able to work either way but let's wait for more people to chime in.

@cdecker

cdecker commented Feb 19, 2018

Copy link
Copy Markdown
Member

I think @rustyrussell will be able to shed some light on our doubts, so deferring final judgement to him ^^

@rustyrussell

rustyrussell commented Feb 20, 2018

Copy link
Copy Markdown
Contributor

I'm going to apply this, ugly as it is. This will make configurator spit out a CCAN_CFLAGS line with "-static" in it, but it works because we don't use that for the actual build.

A proper ./configure step is TBA....

ACK 79efee5

@rustyrussell
rustyrussell merged commit bd95aba into ElementsProject:master Feb 20, 2018
rustyrussell added a commit to rustyrussell/lightning that referenced this pull request Feb 26, 2018
…URATOR_CC

This should solve what @icota wanted in ElementsProject#1035 in a much cleaner way.

In particular, this allows you to say what configurator should use, independent
of what other compilation should use, and reverts the '-static' which broke
MacOS.

Fixes: ElementsProject#1059
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
cdecker pushed a commit that referenced this pull request Feb 26, 2018
…URATOR_CC

This should solve what @icota wanted in #1035 in a much cleaner way.

In particular, this allows you to say what configurator should use, independent
of what other compilation should use, and reverts the '-static' which broke
MacOS.

Fixes: #1059
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.

4 participants