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 <aixto...@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. > > - Ł
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
