Re: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1
Check the code in tools/clang/lib/Driver/Tools.cpp. That specifies the
/libexec/ld-elf.so.1.
On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote:
> # more main.c
> int main()
> {
> return 0;
> }
>
>
>
> # ls -l `which cc`
> -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc
>
> # cc --version
> FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906
> Target: powerpc64-unknown-freebsd11.0
> Thread model: posix
>
> # cc -m32 -mcpu=powerpc main.c
> # file a.out
> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD),
> dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for
> FreeBSD 11.0 (1100091), not stripped
>
>
>
> By contrast powerpc64-gcc binds the a.out produced to /libexec/ld-elf32.so.1
> instead:
>
> # ls -l `which gcc`
> lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc ->
> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
>
> # gcc --version
> gcc (FreeBSD Ports Collection for powerpc64) 5.2.0
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> # gcc -m32 -mcpu=powerpc main.c
> # file a.out
> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD),
> dynamically linked, interpreter /libexec/ld-elf32.so.1, FreeBSD-style, for
> FreeBSD 11.0 (1100091), not stripped
>
>
> Context details:
>
> # freebsd-version -ku; uname -aKU
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r291891M: Wed Dec 9
> 09:15:33 PST 2015
> root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG
> powerpc 1100091 1100091
>
> # pkg info powerpc64-gcc
> powerpc64-gcc-5.2.0_1
> Name : powerpc64-gcc
> Version: 5.2.0_1
> Installed on : Wed Dec 9 02:18:14 2015 PST
> Origin : devel/powerpc64-gcc
> Architecture : freebsd:11:powerpc:64
> Prefix : /usr/local
> Categories : devel
> . . .
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1
On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote:
> # more main.c
> int main()
> {
> return 0;
> }
>
>
>
> # ls -l `which cc`
> -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc
>
> # cc --version
> FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906
> Target: powerpc64-unknown-freebsd11.0
> Thread model: posix
>
> # cc -m32 -mcpu=powerpc main.c
> # file a.out
> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD),
> dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for
> FreeBSD 11.0 (1100091), not stripped
>
>
>
> By contrast powerpc64-gcc binds the a.out produced to /libexec/ld-elf32.so.1
> instead:
>
> # ls -l `which gcc`
> lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc ->
> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
>
> # gcc --version
> gcc (FreeBSD Ports Collection for powerpc64) 5.2.0
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> # gcc -m32 -mcpu=powerpc main.c
> # file a.out
> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD),
> dynamically linked, interpreter /libexec/ld-elf32.so.1, FreeBSD-style, for
> FreeBSD 11.0 (1100091), not stripped
>
This is a bug in gcc, most likely in the spec file. All FreeBSD
ABIs use either /libexec/ld-elf.so.1 or (for older versions)
/usr/libexec/ld-elf.so.1.
>
> Context details:
>
> # freebsd-version -ku; uname -aKU
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r291891M: Wed Dec 9
> 09:15:33 PST 2015
> root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG
> powerpc 1100091 1100091
>
> # pkg info powerpc64-gcc
> powerpc64-gcc-5.2.0_1
> Name : powerpc64-gcc
> Version: 5.2.0_1
> Installed on : Wed Dec 9 02:18:14 2015 PST
> Origin : devel/powerpc64-gcc
> Architecture : freebsd:11:powerpc:64
> Prefix : /usr/local
> Categories : devel
> . . .
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1
On 2015-Dec-15, at 4:36 AM, Konstantin Belousov wrote:
> On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote:
> . . .
>> By contrast powerpc64-gcc binds the a.out produced to /libexec/ld-elf32.so.1
>> instead:
>>
>> # ls -l `which gcc`
>> lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc ->
>> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
>>
>> # gcc --version
>> gcc (FreeBSD Ports Collection for powerpc64) 5.2.0
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> # gcc -m32 -mcpu=powerpc main.c
>> # file a.out
>> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1
>> (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1,
>> FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped
>
> This is a bug in gcc, most likely in the spec file. All FreeBSD
> ABIs use either /libexec/ld-elf.so.1 or (for older versions)
> /usr/libexec/ld-elf.so.1.
If 32 bit code on powerpc64 is supposed to use /libexec/ld-elf.so.1 just like
the 64 bit code is supposed to then. . .
Looks like lang/gcc49 has the same -m32 -mcpu-powerpc ld-elf32.so.1 problem as
powerpc64-gcc:
# grep ld-elf
/usr/obj/portswork/usr/ports/lang/gcc49/work/gcc-4.9-20151202/gcc/config/rs6000/freebsd64.h
#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1"
#define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1"
# grep ld-elf
/usr/obj/portswork/usr/ports/lang/gcc49/work/stage/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/plugin/include/config/rs6000/freebsd64.h
#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1"
#define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1"
Since powerrpc64-gcc is a variant build of gcc5, lang/gcc5 likely has the
problem too.
===
Mark Millard
markmi at dsl-only.net
On 2015-Dec-15, at 4:36 AM, Konstantin Belousov wrote:
On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote:
> # more main.c
> int main()
> {
>return 0;
> }
>
>
>
> # ls -l `which cc`
> -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc
>
> # cc --version
> FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906
> Target: powerpc64-unknown-freebsd11.0
> Thread model: posix
>
> # cc -m32 -mcpu=powerpc main.c
> # file a.out
> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD),
> dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, for
> FreeBSD 11.0 (1100091), not stripped
>
>
>
> By contrast powerpc64-gcc binds the a.out produced to /libexec/ld-elf32.so.1
> instead:
>
> # ls -l `which gcc`
> lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc ->
> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
>
> # gcc --version
> gcc (FreeBSD Ports Collection for powerpc64) 5.2.0
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> # gcc -m32 -mcpu=powerpc main.c
> # file a.out
> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD),
> dynamically linked, interpreter /libexec/ld-elf32.so.1, FreeBSD-style, for
> FreeBSD 11.0 (1100091), not stripped
>
This is a bug in gcc, most likely in the spec file. All FreeBSD
ABIs use either /libexec/ld-elf.so.1 or (for older versions)
/usr/libexec/ld-elf.so.1.
>
> Context details:
>
> # freebsd-version -ku; uname -aKU
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r291891M: Wed Dec 9
> 09:15:33 PST 2015
> root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG
> powerpc 1100091 1100091
>
> # pkg info powerpc64-gcc
> powerpc64-gcc-5.2.0_1
> Name : powerpc64-gcc
> Version: 5.2.0_1
> Installed on : Wed Dec 9 02:18:14 2015 PST
> Origin : devel/powerpc64-gcc
> Architecture : freebsd:11:powerpc:64
> Prefix : /usr/local
> Categories : devel
> . . .
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
powerpc64: powerpc64-gcc, gcc49, gcc5 bind -m32 -mcpu=powerpc a.out to /libexec/ld-elf32.so.1 instead of /libexec/ld-elf.so.1
[This is mostly a re-titling of an earlier freebsd-pcc/freebsd-toolchain
message to correctly identify the problem. I also added the freebsd-ports list
and some content.]
On 2015-Dec-15, at 4:36 AM, Konstantin Belousov wrote:
> On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote:
>
> # more main.c
> int main()
> {
> return 0;
> }
>
> . . .
>> By contrast powerpc64-gcc binds the a.out produced to /libexec/ld-elf32.so.1
>> instead:
>>
>> # ls -l `which gcc`
>> lrwxr-xr-x 1 root wheel 48 Dec 5 05:38 /usr/bin/gcc ->
>> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
>>
>> # gcc --version
>> gcc (FreeBSD Ports Collection for powerpc64) 5.2.0
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> # gcc -m32 -mcpu=powerpc main.c
>> # file a.out
>> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1
>> (FreeBSD), dynamically linked, interpreter /libexec/ld-elf32.so.1,
>> FreeBSD-style, for FreeBSD 11.0 (1100091), not stripped
>
> This is a bug in gcc, most likely in the spec file. All FreeBSD
> ABIs use either /libexec/ld-elf.so.1 or (for older versions)
> /usr/libexec/ld-elf.so.1.
If 32 bit code on powerpc64 is supposed to use /libexec/ld-elf.so.1 just like
the 64 bit code is supposed to then. . .
Looks like lang/gcc49 has the same -m32 -mcpu=powerpc ld-elf32.so.1 problem as
powerpc64-gcc:
# grep ld-elf
/usr/obj/portswork/usr/ports/lang/gcc49/work/gcc-4.9-20151202/gcc/config/rs6000/freebsd64.h
#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1"
#define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1"
# grep ld-elf
/usr/obj/portswork/usr/ports/lang/gcc49/work/stage/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/plugin/include/config/rs6000/freebsd64.h
#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1"
#define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1"
Since powerpc64-gcc is a variant build of gcc5 and also has the above sort of
freebsd64.h content, lang/gcc5 likely has the problem too.
(By contrast the powerpc64 system clang (3.7) binds its -m32 -mcpu-powerpc
a.out output file to /libexec/ld-elf.so.1 .)
Just for reference, my new patch-gcc-freebsd-powerpc64 variant looks like the
following (tabs likely not preserved):
# svnlite diff /usr/ports/devel/powerpc64-gcc
Index: /usr/ports/devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64
===
--- /usr/ports/devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64
(revision 403711)
+++ /usr/ports/devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64
(working copy)
@@ -1,5 +1,5 @@
gcc/config/rs6000/freebsd64.h 2015-11-28 09:06:13.01000 -0800
-+++ gcc/config/rs6000/freebsd64.h 2015-11-28 09:16:10.459373000 -0800
+--- freebsd64.h.orig 2015-01-05 04:33:28.0 -0800
freebsd64.h2015-12-15 09:52:34.63420 -0800
@@ -65,6 +65,13 @@
#define INVALID_64BIT "-m%s not supported in this configuration"
#define INVALID_32BIT INVALID_64BIT
@@ -27,3 +27,21 @@
if (rs6000_isa_flags & OPTION_MASK_EABI) \
{ \
rs6000_isa_flags &= ~OPTION_MASK_EABI;\
+@@ -154,7 +167,7 @@
+ { "link_os_freebsd_spec32", LINK_OS_FREEBSD_SPEC32 }, \
+ { "link_os_freebsd_spec64", LINK_OS_FREEBSD_SPEC64 },
+
+-#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf32.so.1"
++#define FREEBSD_DYNAMIC_LINKER32 "/libexec/ld-elf.so.1"
+ #define FREEBSD_DYNAMIC_LINKER64 "/libexec/ld-elf.so.1"
+
+ #define LINK_OS_FREEBSD_SPEC_DEF32 "\
+@@ -304,7 +317,7 @@
+
+ /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults instead. */
+ #undef WCHAR_TYPE
+-#define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int")
++#define WCHAR_TYPE "int"
+ #undef WCHAR_TYPE_SIZE
+ #define WCHAR_TYPE_SIZE 32
+
The same sort of changes should apply to gcc49 and gcc5.
The WCHAR_TYPE change fixes the powerpc (non-64) base type used for notations
like L". . ." to match FreeBSD's powerpc/powerpc64 context. Otherwise lib32 in
buildworld gets compile errors from the type mismatches --and lots of extra
warnings as well.
===
Mark Millard
markmi at dsl-only.net
On 2015-Dec-15, at 4:36 AM, Konstantin Belousov wrote:
On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote:
> # more main.c
> int main()
> {
> return 0;
> }
>
>
>
> # ls -l `which cc`
> -r-xr-xr-x 7 root wheel 54137976 Dec 14 00:06 /usr/bin/cc
>
> # cc --version
> FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906
> Target: powerpc64-unknown-freebsd11.0
> Thread model: posix
>
> # cc -m32 -mcpu=powerpc main.c
> # file a.out
> a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD),
> dynamically linked, interpreter /
Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix
On 12/15/15 10:54 AM, Mark Millard wrote:
> On 2015-Dec-15, at 10:37 AM, Bryan Drewery wrote:
>>
>> On 12/8/15 2:14 PM, Bryan Drewery wrote:
>>> On 12/7/15 1:33 PM, Mark Millard wrote:
> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote:
>
> Mark Millard wrote:
>> My guess is that it is picking up the
>>
>> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain
>
> You should use ?= if you want this to work.
> There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked
> in the environment of a sub-make.
>
> By using = above, you break that.
That presumes that MAKEOBJDIRPREFIX has not been assigned a default value
before the SRC_ENV_CONF file has been included the first time. If
MAKEOBJDIRPREFIX had been defined already then the ?= would do nothing and
the wrong value would be used.
I believe that the following trace shows that such an assignment of a
default value does happen first, making ?= not work either.
/usr/src/Makefile (head/Makefile 29160) has
> MAKEOBJDIRPREFIX?= /usr/obj
at line 145 (used when it is not using targets/Makefile from the relevant
.if/.else/.endif).
Line 105 has .include and there no others before the
above assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only),
which in turns includes bsd.mkopt.mk (only). That in turn includes nothing
else. So these files and only these files are the involved files before
that assignment as far as I can tell.
None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not
happened yet when
> MAKEOBJDIRPREFIX?= /usr/obj
is executed.
So, if I understand right, MAKEOBJDIRPREFIX is already defined before the
code
> SRC_ENV_CONF?= /etc/src-env.conf
> .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_)
> .-include "${SRC_ENV_CONF}"
> _src_env_conf_included_:.NOTMAIN
> .endif
is executed and so using ?= would not be effective in the included file.
Did I miss something?
>>>
>>>
>>> Yes. sys.mk and src-env.conf are included *before* Makefile. Think of it
>>> as being in line 0.
>>>
>>> Technically you should be able to use MAKEOBJDIRPREFIX in make.conf or
>>> src.conf if you are not using any of the meta mode features (all off by
>>> default).
>>>
>>
>> Clarification: We *could* support this but it does not work today. We
>> can use .OBJDIR to force using a MAKEOBJDIRPREFIX from make.conf but
>> only if we also force creating the directory as well. Getting this all
>> right just ends up falling into the new auto.obj.mk territory anyhow. I
>> do want to expand that to the default build, which would allow setting
>> MAKEOBJDIRPREFIX in src-env.conf.
>
>
> So may be the paragraph below from "man src.conf" should not (yet?) suggest
> that MAKEOBJDIRPREFIX is valid in a file to be referenced by SRC_ENV_CONF:
>
>> The environment of make(1) for the build can be controlled via the
>> SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some
>> examples that may only be set in this file are MAKEOBJDIRPREFIX,
>> WITH_DIRDEPS_BUILD, and WITH_META_MODE as they are environment-only
>> variables.
>
>
Yes, I fixed it after my mail.
--
Regards,
Bryan Drewery
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix
On 12/8/15 2:14 PM, Bryan Drewery wrote:
> On 12/7/15 1:33 PM, Mark Millard wrote:
>>
>>> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote:
>>>
>>> Mark Millard wrote:
My guess is that it is picking up the
MAKEOBJDIRPREFIX=/usr/obj/xtoolchain
>>>
>>> You should use ?= if you want this to work.
>>> There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked
>>> in the environment of a sub-make.
>>>
>>> By using = above, you break that.
>>
>> That presumes that MAKEOBJDIRPREFIX has not been assigned a default value
>> before the SRC_ENV_CONF file has been included the first time. If
>> MAKEOBJDIRPREFIX had been defined already then the ?= would do nothing and
>> the wrong value would be used.
>>
>> I believe that the following trace shows that such an assignment of a
>> default value does happen first, making ?= not work either.
>>
>>
>>
>> /usr/src/Makefile (head/Makefile 29160) has
>>
>>> MAKEOBJDIRPREFIX?= /usr/obj
>>
>> at line 145 (used when it is not using targets/Makefile from the relevant
>> .if/.else/.endif).
>>
>> Line 105 has .include and there no others before the above
>> assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only), which in
>> turns includes bsd.mkopt.mk (only). That in turn includes nothing else. So
>> these files and only these files are the involved files before that
>> assignment as far as I can tell.
>>
>> None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not happened
>> yet when
>>
>>> MAKEOBJDIRPREFIX?= /usr/obj
>>
>> is executed.
>>
>> So, if I understand right, MAKEOBJDIRPREFIX is already defined before the
>> code
>>
>>> SRC_ENV_CONF?= /etc/src-env.conf
>>> .if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_)
>>> .-include "${SRC_ENV_CONF}"
>>> _src_env_conf_included_:.NOTMAIN
>>> .endif
>>
>> is executed and so using ?= would not be effective in the included file.
>>
>> Did I miss something?
>
>
> Yes. sys.mk and src-env.conf are included *before* Makefile. Think of it
> as being in line 0.
>
> Technically you should be able to use MAKEOBJDIRPREFIX in make.conf or
> src.conf if you are not using any of the meta mode features (all off by
> default).
>
Clarification: We *could* support this but it does not work today. We
can use .OBJDIR to force using a MAKEOBJDIRPREFIX from make.conf but
only if we also force creating the directory as well. Getting this all
right just ends up falling into the new auto.obj.mk territory anyhow. I
do want to expand that to the default build, which would allow setting
MAKEOBJDIRPREFIX in src-env.conf.
--
Regards,
Bryan Drewery
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix
On 2015-Dec-15, at 10:37 AM, Bryan Drewery wrote:
>
> On 12/8/15 2:14 PM, Bryan Drewery wrote:
>> On 12/7/15 1:33 PM, Mark Millard wrote:
>>>
On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote:
Mark Millard wrote:
> My guess is that it is picking up the
>
> MAKEOBJDIRPREFIX=/usr/obj/xtoolchain
You should use ?= if you want this to work.
There are many places in Makefile.inc1 where MAKEOBJDIRPREFIX is tweaked
in the environment of a sub-make.
By using = above, you break that.
>>>
>>> That presumes that MAKEOBJDIRPREFIX has not been assigned a default value
>>> before the SRC_ENV_CONF file has been included the first time. If
>>> MAKEOBJDIRPREFIX had been defined already then the ?= would do nothing and
>>> the wrong value would be used.
>>>
>>> I believe that the following trace shows that such an assignment of a
>>> default value does happen first, making ?= not work either.
>>>
>>>
>>>
>>> /usr/src/Makefile (head/Makefile 29160) has
>>>
MAKEOBJDIRPREFIX?= /usr/obj
>>>
>>> at line 145 (used when it is not using targets/Makefile from the relevant
>>> .if/.else/.endif).
>>>
>>> Line 105 has .include and there no others before the
>>> above assignment. bsd.compiler.mk in turn includes bsd.opt.mk (only), which
>>> in turns includes bsd.mkopt.mk (only). That in turn includes nothing else.
>>> So these files and only these files are the involved files before that
>>> assignment as far as I can tell.
>>>
>>> None of these get to src.sys.env.mk and so SRC_ENV_CONF use has not
>>> happened yet when
>>>
MAKEOBJDIRPREFIX?= /usr/obj
>>>
>>> is executed.
>>>
>>> So, if I understand right, MAKEOBJDIRPREFIX is already defined before the
>>> code
>>>
SRC_ENV_CONF?= /etc/src-env.conf
.if !empty(SRC_ENV_CONF) && !target(_src_env_conf_included_)
.-include "${SRC_ENV_CONF}"
_src_env_conf_included_:.NOTMAIN
.endif
>>>
>>> is executed and so using ?= would not be effective in the included file.
>>>
>>> Did I miss something?
>>
>>
>> Yes. sys.mk and src-env.conf are included *before* Makefile. Think of it
>> as being in line 0.
>>
>> Technically you should be able to use MAKEOBJDIRPREFIX in make.conf or
>> src.conf if you are not using any of the meta mode features (all off by
>> default).
>>
>
> Clarification: We *could* support this but it does not work today. We
> can use .OBJDIR to force using a MAKEOBJDIRPREFIX from make.conf but
> only if we also force creating the directory as well. Getting this all
> right just ends up falling into the new auto.obj.mk territory anyhow. I
> do want to expand that to the default build, which would allow setting
> MAKEOBJDIRPREFIX in src-env.conf.
So may be the paragraph below from "man src.conf" should not (yet?) suggest
that MAKEOBJDIRPREFIX is valid in a file to be referenced by SRC_ENV_CONF:
> The environment of make(1) for the build can be controlled via the
> SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some
> examples that may only be set in this file are MAKEOBJDIRPREFIX,
> WITH_DIRDEPS_BUILD, and WITH_META_MODE as they are environment-only
> variables.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
