On 04/05/12 14:22, Edwin Beasant wrote:
During my testing of the ksh93 Userland putback, I've come across a
probable gmake bug that breaks the openssl compile, but only when my new
prep.mk file is used.
I've spent quite a bit of time tracing this, and have reached a couple of
conclusions:
The bug is triggered by extra-long target-specific variable assignments
containing at least one semicolon - in particular this occurs in the
openssl-1.0.0 makefile, but only on SPARC (it is conditionally compiled) where
paths are used in the target-specific variable assignment for
COMPONENT_POST_INSTALL.
In the openssl case, having a long path to the workspace you are working in
will trigger this bug *in the normal clean userland build*, but it is exposed
more by the changes I have made to the prep.mk file.
The bug is this: on a target-specific variable, if the assignment of the
variable a semicolon(s) and is over 150 characters in length, then the
assignment is truncated at the first semicolon or an error is thrown (this
occurs with line continuation slashes as well).
Test makefile:
(also attached)
(note that a; eeee etc is all on the same line)
a : SOME_VAR = "a;
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee"
# 'e' x 130+ characters
a :
@echo $(SOME_VAR)
bash $ gmake -f test.makefile a
test.makefile:1: *** Malformed target-specific variable definition. Stop.
bash-4.1$ gmake --version
GNU Make 3.82
Remove one 'e' or a semicolon from the above and it suddenly works.
A similar bug was meant to have been fixed in an earlier version of gmake, but
the test suite for gmake claims that it passes the bug test fix - I'm currently
investigating this, but I believe that the test only checks using plain
characters, and does not introduce any semicolons.
It is my best guess that the introduction of the semicolon trips the gmake
recipe parsing code, and it hits the 150 command line character limit
(originally imposed by DOS(!)), even though this is a target-specfic variable
(not a recipe), and on UNIX, not DOS. I have yet to fully trace this in the
code.
I have filed a bug for this:
http://monaco.us.oracle.com/detail.jsf?cr=7159246
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
Hi Edwin,
sorry for not having discovered this myself before pushing the change. I
have 20 build logs without hitting the bug, but testing build with long
path to workspace didn't come to mind...
Just FYI, I am hoping to push
http://monaco.us.oracle.com/detail.jsf?cr=7156086 in current build, and
I will no longer use target specific variable for copying-in
wanboot-openssl.o.
In case you were interested, webrev:
http://kodiak.us.oracle.com/builds/tkuthan/ul-wanboot-rebuilt/webrev3/
Thanks,
Tomas
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
