<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Yes, unintended. It was only supposed to be signed, but "Send
Later" encrypts it.</p>
<p>Unpacked version:</p>
<p> </p>
<div class="moz-text-html" lang="x-unicode">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/2/2018 1:07 AM, Benjamin
Peterson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1538435240.4040554.1527177920.188EFF58@webmail.messagingengine.com">
<div class="moz-text-plain" wrap="true" style="font-family:
-moz-fixed; font-size: 14px;" lang="x-unicode">
<pre wrap="">On Mon, Oct 1, 2018, at 12:12, Michael Felt wrote:
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">I think you should just put it in LDFLAGS.</pre>
</div>
</blockquote>
I was wanting to avoid that, as LDFLAGS is an environmental
variable. <br>
<br>
At the surface, it appears Python is using PY_LDFLAGS (with
CONFIGURE_LDFLAGS coming from LDFLAGS during the ./configure
moment.<br>
<br>
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:<br>
<br>
root@x066:[/data/prj/python/git/cpython-master]grep LDFLAGS *.in<br>
Makefile.pre.in:CONFIGURE_LDFLAGS= @LDFLAGS@<br>
Makefile.pre.in:# Avoid assigning CFLAGS, LDFLAGS, etc. so users
can use them on the<br>
Makefile.pre.in:# Both CPPFLAGS and LDFLAGS need to contain the
shell's value for setup.py to<br>
Makefile.pre.in:PY_LDFLAGS= $(CONFIGURE_LDFLAGS) $(LDFLAGS)<br>
Makefile.pre.in:LDSHARED= @LDSHARED@ $(PY_LDFLAGS)<br>
Makefile.pre.in:BLDSHARED= @BLDSHARED@ $(PY_LDFLAGS)<br>
Makefile.pre.in:OPENSSL_LDFLAGS=@OPENSSL_LDFLAGS@<br>
Makefile.pre.in: $(MAKE) @DEF_MAKE_RULE@
CFLAGS_NODIST="$(CFLAGS) $(PGO_PROF_GEN_FLAG)" LDFLAGS="$(LDFLAGS)
$(PGO_PROF_GEN_FLAG)" LIBS="$(LIBS)"<br>
Makefile.pre.in: $(MAKE) @DEF_MAKE_RULE@
CFLAGS_NODIST="$(CFLAGS) $(PGO_PROF_USE_FLAG)"
LDFLAGS="$(LDFLAGS)"<br>
Makefile.pre.in: $(LINKCC) $(PY_LDFLAGS) $(LINKFORSHARED)
-o $@ Programs/python.o $(BLDLIBRARY) $(LIBS) $(MODLIBS)
$(SYSLIBS) $(LDLAST)<br>
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); \<br>
Makefile.pre.in: $(CC) -o $(LDLIBRARY) $(PY_LDFLAGS)
-dynamiclib \<br>
Makefile.pre.in: $(LINKCC) $(PY_LDFLAGS) $(LINKFORSHARED)
-o $@ Programs/_testembed.o $(BLDLIBRARY) $(LIBS) $(MODLIBS)
$(SYSLIBS) $(LDLAST)<br>
Makefile.pre.in: $(LINKCC) $(PY_LDFLAGS) -o $@
Programs/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN) $(LIBS)
$(MODLIBS) $(SYSLIBS) $(LDLAST)<br>
Makefile.pre.in: $(CC) $(OPT) $(PY_LDFLAGS)
$(PGENOBJS) $(LIBS) -o $(PGEN)<br>
<br>
The ONLY line that needs $LDMAXDATA is:<br>
<br>
Makefile.pre.in: $(LINKCC) $(PY_LDFLAGS) -o $@
Programs/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN) $(LIBS)
$(MODLIBS) $(SYSLIBS) $(LDLAST) $(LDMAXDATA)<br>
<br>
or set $(LDLAST) at the end rather than append $(LDMAXDATA)<br>
<blockquote type="cite"
cite="mid:1538435240.4040554.1527177920.188EFF58@webmail.messagingengine.com">
<div class="moz-text-plain" wrap="true" style="font-family:
-moz-fixed; font-size: 14px;" lang="x-unicode">
<blockquote type="cite" style="color: #000000;">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">LDLAST looks vestigial from OSF/1 support and should probably be removed.
</pre>
</div>
</blockquote>
<br>
</div>
<br>
<div class="moz-cite-prefix">On 10/2/2018 2:51 PM, Łukasz Langa
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DD7CAA94-87F6-4637-93E3-089FF62A6C5C@langa.pl">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">On 2 Oct 2018, at 12:29, Michael Felt <a class="moz-txt-link-rfc2396E" href="mailto:aixtools@felt.demon.nl"><aixtools@felt.demon.nl></a> wrote:
<mime-attachment><encrypted.asc>
</pre>
</blockquote>
<pre wrap="">
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.
- Ł
</pre>
</blockquote>
<br>
</body>
</html>