[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160504180923.GT21636@brightrain.aerifal.cx>
Date: Wed, 4 May 2016 14:09:23 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: j-core@...ore.org
Subject: Re: Re: [J-core] musl-cross-make / litecross improvements
On Wed, May 04, 2016 at 07:16:56PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2016-05-04 12:33:29 -0400]:
> > On Wed, May 04, 2016 at 04:28:18AM -0500, Rob Landley wrote:
> > > Still no native toolchains. :)
> >
> > In theory all you have to do to get a native toolchain is first build
> > and install the cross toolchain so that the cross tools are in your
> > path, then COMMON_CONFIG += --host=$(TARGET). I can test and see if it
> > works.
> >
> > Of course it's somewhat large to install on small systems like J2 but
> > I think you could run it from the sdcard.
>
> i tried it for x86_64 and with the following config.mak change
>
> ifeq ($(NATIVE),yes)
> COMMON_CONFIG += --host=$(TARGET)
> OUTPUT = $(PWD)/output-native
In principle I think OUTPUT should be left to the user, but native
compilers are somewhat different since you can't install a bunch of
them in the same location. Not sure what the best way to handle that
is.
> BUILD_DIR = build-$(TARGET)-native
> XGCC = $(TARGET)-gcc
Also the AR and RANLIB passed to musl's make are wrong (they don't run
on the build system). Passing --host to musl's build system (always)
and omitting the AR/RANLIB vars on the make command line (in NATIVE
mode only) is the right solution, I think.
> PATH_ORIG := $(PATH)
> export PATH = $(PWD)/output/bin:$(PATH_ORIG)
This type of approach makes sense for scripting a build in the same
tree, but I don't think we're ready for integrating that sort of
process. It would require rules/dependencies to build the appropriate
cross compiler to begin with and install it to a controlled location
under the build dir. Since native compilers are not really the point
(and easy to do by yourself without litecross; arguably even easier) I
think I'd rather just assume that if the user wants to use litecross
for a native compiler they can either install the necessary cross
compiler in their path or update PATH on their own.
> endif
>
> make install && make install NATIVE=yes
>
> built a native toolchain into output-native
> (it still installs musl into a $(TARGET) subdir, but
> i think that's just a matter of copying things around.)
It's easy to change that just by changing the DESTDIR passed to musl's
"make install".
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
