Yes, unintended. It was only supposed to be signed, but "Send Later" encrypts it. Unpacked version: On 10/2/2018 1:07 AM, Benjamin Peterson wrote:
On Mon, Oct 1, 2018, at 12:12, Michael Felt wrote:
Hi all,
Before I submit a patch to increase the default MAXDATA setting for AIX when in 32-bit mode - I want to know if I can put this LDFLAG setting in LDLAST, or if I should introduce a new AC_SUBST() variable (e.g., LDMAXDATA). I think you should just put it in LDFLAGS. I was wanting to avoid that, as LDFLAGS is an environmental variable.
At the surface, it appears Python is using PY_LDFLAGS (with CONFIGURE_LDFLAGS coming from LDFLAGS during the ./configure moment. A reason for a separate variable is that this particular option is only relevant for the python EXE, and not for shared libraries and "other things". IMHO, a reason for LDMAXDATA is because LDLAST is actually already too widely used: root@x066:[/data/prj/python/git/cpython-master]grep LDFLAGS *.in Makefile.pre.in:CONFIGURE_LDFLAGS= @LDFLAGS@ Makefile.pre.in:# Avoid assigning CFLAGS, LDFLAGS, etc. so users can use them on the Makefile.pre.in:# Both CPPFLAGS and LDFLAGS need to contain the shell's value for setup.py to Makefile.pre.in:PY_LDFLAGS= $(CONFIGURE_LDFLAGS) $(LDFLAGS) Makefile.pre.in:LDSHARED= @LDSHARED@ $(PY_LDFLAGS) Makefile.pre.in:BLDSHARED= @BLDSHARED@ $(PY_LDFLAGS) Makefile.pre.in:OPENSSL_LDFLAGS=@OPENSSL_LDFLAGS@ Makefile.pre.in: $(MAKE) @DEF_MAKE_RULE@ CFLAGS_NODIST="$(CFLAGS) $(PGO_PROF_GEN_FLAG)" LDFLAGS="$(LDFLAGS) $(PGO_PROF_GEN_FLAG)" LIBS="$(LIBS)" Makefile.pre.in: $(MAKE) @DEF_MAKE_RULE@ CFLAGS_NODIST="$(CFLAGS) $(PGO_PROF_USE_FLAG)" LDFLAGS="$(LDFLAGS)" Makefile.pre.in: $(LINKCC) $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Programs/python.o $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST) Makefile.pre.in: $(CC) -dynamiclib -Wl,-single_module $(PY_LDFLAGS) -undefined dynamic_lookup -Wl,-install_name,$(prefix)/lib/libpython$(LDVERSION).dylib -Wl,-compatibility_version,$(VERSION) -Wl,-current_version,$(VERSION) -o $@ $(LIBRARY_OBJS) $(SHLIBS) $(LIBC) $(LIBM) $(LDLAST); \ Makefile.pre.in: $(CC) -o $(LDLIBRARY) $(PY_LDFLAGS) -dynamiclib \ Makefile.pre.in: $(LINKCC) $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Programs/_testembed.o $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST) Makefile.pre.in: $(LINKCC) $(PY_LDFLAGS) -o $@ Programs/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST) Makefile.pre.in: $(CC) $(OPT) $(PY_LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN) The ONLY line that needs $LDMAXDATA is: Makefile.pre.in: $(LINKCC) $(PY_LDFLAGS) -o $@ Programs/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST) $(LDMAXDATA) or set $(LDLAST) at the end rather than append $(LDMAXDATA)
I have not looked yet, but I was thinking that MAYBE! LDLAST is intended as a last resort variable that can be modified in Makefile. LDLAST looks vestigial from OSF/1 support and should probably be removed.
On 10/2/2018 2:51 PM, Łukasz Langa wrote:
On 2 Oct 2018, at 12:29, Michael Felt <aixtools@felt.demon.nl> wrote:
<mime-attachment><encrypted.asc> Michael, this message looks encrypted on my end. For people without your public key, it's impossible to read. This was probably unintentional on your end. In either case I'd avoid encrypting messages that go to public mailing lists.
- Ł