[openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles
On Wed May 11 10:51:46 2016, rainer.j...@kippdata.de wrote:
> Am 10.05.2016 um 21:54 schrieb Richard Levitte via RT:
> > I understand this part. What I'm questioning is the need to set PERL
> > to
> > "/usr/bin/env perl" to begin with. It's practically not different at
> > all from
> > setting it to just "perl", all this does is that any time the
> > environment
> > variable PERL is used to run a perl script is to have an extra
> > process between
> > the shell and perl itself that will simply pass along the exact
> > environment
> > that it got from the shell. In effect, any time the environment
> > variable PERL
> > with your assignment is used to run a script (assuming the quoting
> > you
> > suggest), i.e.:
> >
> > $PERL blah.pl
> >
> > it would expand to this:
> >
> > /usr/bin/env perl blah.pl
> >
> > If it's only assigned "perl", the command would expand to this:
> >
> > perl blah.pl
> >
> > perl itself literally gets the exact same environment in both cases.
>
> I agree.
>
> > Mind you, I did read your reasoning around #! in scripts.
> > Unfortunately, that
> > reasoning is flawed, that won't be affected by the environment
> > variable PERL.
>
> I had to rad my ticket again, and actually this is the only reason for
> the ticket: the following perl scripts are generated from .in files
> during building OpenSSL and get installed and executed later in
> another
> environment:
>
> - c_rehash
> - CA.pl
> - tsget
>
> All of them contain in the .in file the magic header:
>
> #!{- $config{perl} -}
>
> IMHO $config{perl} - detected and set during config and Configure from
> the PERL env var and as a fallback from the PATH - is used as the perl
> during build time and also put into the scripts for use on the target
> system.
>
> But those two perl paths should be defined independently from each
> other.
>
> You say the reasoning is flawed, but to me it looks like:
>
> - config checks whether the PERL env var is set. If not it searches
> for
> a perl in the path and sets the PERL env var to that one.
>
> - config calls Configure
>
> - Configure sets $config{perl} from the PERL env var
>
> - the scripts c_rehash, CA.pl and tsget are generated from their .in
> files and their first line
>
> #!{- $config{perl} -}
>
> is replaced by #!$PERL (with $PERL resolved).
>
> I'd love if I were wrong and there would already be a way to set the
> perl for those scripts independently from the one used for the build
> process. If you think that demand is too specific, I can live with
> patching the scripts myself. But IMHO it would be nice not to enforce
> the same restrictions on the build procedure perl to the runtime perl
> for those simple scripts. For the build procedure it should be the
> required 5.10 with modules etc. For the three scripts typically the
> platform perl would suffice.
Thanks for your explanation. Your patch has just made it to the master branch.
Closing this ticket.
Cheers,
Richard
--
Richard Levitte
levi...@openssl.org
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles
Am 10.05.2016 um 21:54 schrieb Richard Levitte via RT:
I understand this part. What I'm questioning is the need to set PERL to
"/usr/bin/env perl" to begin with. It's practically not different at all from
setting it to just "perl", all this does is that any time the environment
variable PERL is used to run a perl script is to have an extra process between
the shell and perl itself that will simply pass along the exact environment
that it got from the shell. In effect, any time the environment variable PERL
with your assignment is used to run a script (assuming the quoting you
suggest), i.e.:
$PERL blah.pl
it would expand to this:
/usr/bin/env perl blah.pl
If it's only assigned "perl", the command would expand to this:
perl blah.pl
perl itself literally gets the exact same environment in both cases.
I agree.
Mind you, I did read your reasoning around #! in scripts. Unfortunately, that
reasoning is flawed, that won't be affected by the environment variable PERL.
I had to rad my ticket again, and actually this is the only reason for
the ticket: the following perl scripts are generated from .in files
during building OpenSSL and get installed and executed later in another
environment:
- c_rehash
- CA.pl
- tsget
All of them contain in the .in file the magic header:
#!{- $config{perl} -}
IMHO $config{perl} - detected and set during config and Configure from
the PERL env var and as a fallback from the PATH - is used as the perl
during build time and also put into the scripts for use on the target
system.
But those two perl paths should be defined independently from each other.
You say the reasoning is flawed, but to me it looks like:
- config checks whether the PERL env var is set. If not it searches for
a perl in the path and sets the PERL env var to that one.
- config calls Configure
- Configure sets $config{perl} from the PERL env var
- the scripts c_rehash, CA.pl and tsget are generated from their .in
files and their first line
#!{- $config{perl} -}
is replaced by #!$PERL (with $PERL resolved).
I'd love if I were wrong and there would already be a way to set the
perl for those scripts independently from the one used for the build
process. If you think that demand is too specific, I can live with
patching the scripts myself. But IMHO it would be nice not to enforce
the same restrictions on the build procedure perl to the runtime perl
for those simple scripts. For the build procedure it should be the
required 5.10 with modules etc. For the three scripts typically the
platform perl would suffice.
Regards,
Rainer
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles
Am 10.05.2016 um 21:54 schrieb Richard Levitte via RT:
> I understand this part. What I'm questioning is the need to set PERL to
> "/usr/bin/env perl" to begin with. It's practically not different at all from
> setting it to just "perl", all this does is that any time the environment
> variable PERL is used to run a perl script is to have an extra process between
> the shell and perl itself that will simply pass along the exact environment
> that it got from the shell. In effect, any time the environment variable PERL
> with your assignment is used to run a script (assuming the quoting you
> suggest), i.e.:
>
> $PERL blah.pl
>
> it would expand to this:
>
> /usr/bin/env perl blah.pl
>
> If it's only assigned "perl", the command would expand to this:
>
> perl blah.pl
>
> perl itself literally gets the exact same environment in both cases.
I agree.
> Mind you, I did read your reasoning around #! in scripts. Unfortunately, that
> reasoning is flawed, that won't be affected by the environment variable PERL.
I had to rad my ticket again, and actually this is the only reason for
the ticket: the following perl scripts are generated from .in files
during building OpenSSL and get installed and executed later in another
environment:
- c_rehash
- CA.pl
- tsget
All of them contain in the .in file the magic header:
#!{- $config{perl} -}
IMHO $config{perl} - detected and set during config and Configure from
the PERL env var and as a fallback from the PATH - is used as the perl
during build time and also put into the scripts for use on the target
system.
But those two perl paths should be defined independently from each other.
You say the reasoning is flawed, but to me it looks like:
- config checks whether the PERL env var is set. If not it searches for
a perl in the path and sets the PERL env var to that one.
- config calls Configure
- Configure sets $config{perl} from the PERL env var
- the scripts c_rehash, CA.pl and tsget are generated from their .in
files and their first line
#!{- $config{perl} -}
is replaced by #!$PERL (with $PERL resolved).
I'd love if I were wrong and there would already be a way to set the
perl for those scripts independently from the one used for the build
process. If you think that demand is too specific, I can live with
patching the scripts myself. But IMHO it would be nice not to enforce
the same restrictions on the build procedure perl to the runtime perl
for those simple scripts. For the build procedure it should be the
required 5.10 with modules etc. For the three scripts typically the
platform perl would suffice.
Regards,
Rainer
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles
On Tue May 10 14:56:16 2016, rainer.j...@kippdata.de wrote: > Am 10.05.2016 um 15:29 schrieb Richard Levitte via RT: > > On Tue May 10 13:18:22 2016, matt wrote: > >> Makefile.in doesn't exist any more. Ping Richard Levitte - does > >> anything need > >> to be done for the new build system? > > > > The run_tests.pl line in Configurations/unix-Makefile.tmpl would > > still need > > that change... > > > > ... but I don't quite understand the background story. What you end > > up with is > > perl calls like this: > > > > /usr/bin/env perl ... blah ... > > > > and the difference between that and this is nil: > > > > perl ... blah ... > > No, this is about lines which set the PERL shell variable from the > Makefile variable and then run a command on the same line, e.g. > > PERL=$(PERL) /path/to/something > > Now if the Makefile variable PERL is set to > > PERL=/usr/bin/env perl I understand this part. What I'm questioning is the need to set PERL to "/usr/bin/env perl" to begin with. It's practically not different at all from setting it to just "perl", all this does is that any time the environment variable PERL is used to run a perl script is to have an extra process between the shell and perl itself that will simply pass along the exact environment that it got from the shell. In effect, any time the environment variable PERL with your assignment is used to run a script (assuming the quoting you suggest), i.e.: $PERL blah.pl it would expand to this: /usr/bin/env perl blah.pl If it's only assigned "perl", the command would expand to this: perl blah.pl perl itself literally gets the exact same environment in both cases. Mind you, I did read your reasoning around #! in scripts. Unfortunately, that reasoning is flawed, that won't be affected by the environment variable PERL. Cheers, Richard -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles
Am 10.05.2016 um 15:29 schrieb Richard Levitte via RT:
> On Tue May 10 13:18:22 2016, matt wrote:
>> Makefile.in doesn't exist any more. Ping Richard Levitte - does
>> anything need
>> to be done for the new build system?
>
> The run_tests.pl line in Configurations/unix-Makefile.tmpl would still need
> that change...
>
> ... but I don't quite understand the background story. What you end up with is
> perl calls like this:
>
> /usr/bin/env perl ... blah ...
>
> and the difference between that and this is nil:
>
> perl ... blah ...
No, this is about lines which set the PERL shell variable from the
Makefile variable and then run a command on the same line, e.g.
PERL=$(PERL) /path/to/something
Now if the Makefile variable PERL is set to
PERL=/usr/bin/env perl
without quotes the shell command resolves to:
PERL=/usr/bin/env perl /path/to/something
so we call perl with argument /path/to/something and environment
variable PERL set to /usr/bin/env.
With quotes it is
PERL="/usr/bin/env perl" /path/to/something
so we call /path/to/something with PERL env var set to "/usr/bin/env perl".
Currently (1.1.0pre5) I patch only one file before building, the
unix-Makefile.tmpl file:
--- ./Configurations/unix-Makefile.tmpl.orig2016-04-19
18:51:16.0 +0200
+++ ./Configurations/unix-Makefile.tmpl 2016-04-19 19:39:11.0 +0200
@@ -231,7 +231,7 @@
@ : {- output_on() if !$disabled{tests}; "" -}
list-tests:
- @TOP=$(SRCDIR) PERL=$(PERL) $(PERL) $(SRCDIR)/test/run_tests.pl list
+ @TOP=$(SRCDIR) PERL="$(PERL)" $(PERL)
$(SRCDIR)/test/run_tests.pl list
libclean:
@set -e; for s in $(SHLIB_INFO); do \
@@ -939,7 +939,7 @@
$target: $lib$libext $deps $ordinalsfile
\$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
PLATFORM=\$(PLATFORM) \\
- PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+ PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
INSTALLTOP='\$(INSTALLTOP)' LIBDIR='\$(LIBDIR)' \\
LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
LIBNAME=$libname
LIBVERSION=\$(SHLIB_MAJOR).\$(SHLIB_MINOR) \\
@@ -975,7 +975,7 @@
$target: $objs $deps
\$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
PLATFORM=\$(PLATFORM) \\
- PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+ PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
LIBDEPS='\$(PLIB_LDFLAGS) '"$shlibdeps"' \$(EX_LIBS)' \\
LIBNAME=$libname LDFLAGS='\$(LDFLAGS)' \\
CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(DSO_CFLAGS)' \\
@@ -1012,7 +1012,7 @@
$bin$exeext: $objs $deps
\$(RM) $bin$exeext
\$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
- PERL=\$(PERL) SRCDIR=\$(SRCDIR) \\
+ PERL="\$(PERL)" SRCDIR=\$(SRCDIR) \\
APPNAME=$bin$exeext OBJECTS="$objs" \\
LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(BIN_CFLAGS)' \\
I haven't checked for other platform files though.
Regards,
Rainer
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles
Am 10.05.2016 um 15:29 schrieb Richard Levitte via RT:
On Tue May 10 13:18:22 2016, matt wrote:
Makefile.in doesn't exist any more. Ping Richard Levitte - does
anything need
to be done for the new build system?
The run_tests.pl line in Configurations/unix-Makefile.tmpl would still need
that change...
... but I don't quite understand the background story. What you end up with is
perl calls like this:
/usr/bin/env perl ... blah ...
and the difference between that and this is nil:
perl ... blah ...
No, this is about lines which set the PERL shell variable from the
Makefile variable and then run a command on the same line, e.g.
PERL=$(PERL) /path/to/something
Now if the Makefile variable PERL is set to
PERL=/usr/bin/env perl
without quotes the shell command resolves to:
PERL=/usr/bin/env perl /path/to/something
so we call perl with argument /path/to/something and environment
variable PERL set to /usr/bin/env.
With quotes it is
PERL="/usr/bin/env perl" /path/to/something
so we call /path/to/something with PERL env var set to "/usr/bin/env perl".
Currently (1.1.0pre5) I patch only one file before building, the
unix-Makefile.tmpl file:
--- ./Configurations/unix-Makefile.tmpl.orig2016-04-19
18:51:16.0 +0200
+++ ./Configurations/unix-Makefile.tmpl 2016-04-19 19:39:11.0 +0200
@@ -231,7 +231,7 @@
@ : {- output_on() if !$disabled{tests}; "" -}
list-tests:
- @TOP=$(SRCDIR) PERL=$(PERL) $(PERL) $(SRCDIR)/test/run_tests.pl list
+ @TOP=$(SRCDIR) PERL="$(PERL)" $(PERL)
$(SRCDIR)/test/run_tests.pl list
libclean:
@set -e; for s in $(SHLIB_INFO); do \
@@ -939,7 +939,7 @@
$target: $lib$libext $deps $ordinalsfile
\$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
PLATFORM=\$(PLATFORM) \\
- PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+ PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
INSTALLTOP='\$(INSTALLTOP)' LIBDIR='\$(LIBDIR)' \\
LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
LIBNAME=$libname
LIBVERSION=\$(SHLIB_MAJOR).\$(SHLIB_MINOR) \\
@@ -975,7 +975,7 @@
$target: $objs $deps
\$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
PLATFORM=\$(PLATFORM) \\
- PERL=\$(PERL) SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
+ PERL="\$(PERL)" SRCDIR='\$(SRCDIR)' DSTDIR="$libd" \\
LIBDEPS='\$(PLIB_LDFLAGS) '"$shlibdeps"' \$(EX_LIBS)' \\
LIBNAME=$libname LDFLAGS='\$(LDFLAGS)' \\
CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(DSO_CFLAGS)' \\
@@ -1012,7 +1012,7 @@
$bin$exeext: $objs $deps
\$(RM) $bin$exeext
\$(MAKE) -f \$(SRCDIR)/Makefile.shared -e \\
- PERL=\$(PERL) SRCDIR=\$(SRCDIR) \\
+ PERL="\$(PERL)" SRCDIR=\$(SRCDIR) \\
APPNAME=$bin$exeext OBJECTS="$objs" \\
LIBDEPS='\$(PLIB_LDFLAGS) '"$linklibs"' \$(EX_LIBS)' \\
CC='\$(CC)' CFLAGS='\$(CFLAGS) \$(BIN_CFLAGS)' \\
I haven't checked for other platform files though.
Regards,
Rainer
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles
On Tue May 10 13:18:22 2016, matt wrote: > Makefile.in doesn't exist any more. Ping Richard Levitte - does > anything need > to be done for the new build system? The run_tests.pl line in Configurations/unix-Makefile.tmpl would still need that change... ... but I don't quite understand the background story. What you end up with is perl calls like this: /usr/bin/env perl ... blah ... and the difference between that and this is nil: perl ... blah ... -- Richard Levitte levi...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles
Makefile.in doesn't exist any more. Ping Richard Levitte - does anything need to be done for the new build system? Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles
Hi there, I built OpenSSL 1.1.0-pre3 with PERL="/usr/bin/env perl" This has the nice effect, that any generated perl artefact that itself uses perl via the "#!" notation contains #!/usr/bin/env perl and not the perl path to which "/usr/bin/env perl" resolves during build time on the build machine. The only tweak I had to apply to make this work, was quoting a few lines that use PERL=$(PERL) in Makefile.in: --- Makefile.in 2016-02-15 20:51:46.0 +0100 +++ Makefile.in 2016-02-16 00:28:16.51073 +0100 @@ -512,8 +512,8 @@ errors: $(PERL) util/ck_errf.pl -strict */*.c */*/*.c $(PERL) util/mkerr.pl -recurse -write - (cd engines; $(MAKE) PERL=$(PERL) errors) - (cd crypto/ct; $(MAKE) PERL=$(PERL) errors) + (cd engines; $(MAKE) PERL="$(PERL)" errors) + (cd crypto/ct; $(MAKE) PERL="$(PERL)" errors) ordinals: util/libeay.num util/ssleay.num test_ordinals TABLE util/libeay.num:: @@ -521,7 +521,7 @@ util/ssleay.num:: $(PERL) util/mkdef.pl ssl update test_ordinals: - TOP=$(TOP) PERL=$(PERL) $(PERL) test/run_tests.pl test_ordinals + TOP=$(TOP) PERL="$(PERL)" $(PERL) test/run_tests.pl test_ordinals TABLE: Configure Configurations/*.conf (echo 'Output of `Configure TABLE'"':"; \ --- test/Makefile.in 2016-02-15 20:51:48.0 +0100 +++ test/Makefile.in2016-02-16 00:28:16.545897000 +0100 @@ -155,12 +155,12 @@ @sh $(TOP)/util/point.sh dummytest.c $@ tests: exe apps - TOP=$(TOP) PERL=$(PERL) $(PERL) run_tests.pl $(TESTS) + TOP=$(TOP) PERL="$(PERL)" $(PERL) run_tests.pl $(TESTS) errors: list-tests: - @TOP=$(TOP) PERL=$(PERL) $(PERL) run_tests.pl list + @TOP=$(TOP) PERL="$(PERL)" $(PERL) run_tests.pl list apps: @(cd ..; $(MAKE) DIRS=apps all) You might want to consider this change. Looking through all assignments in Makefile.in files and ignoring the possible use of paths with spaces (people shouldn't use them), i see one other line which might benefit from quoting. It is in test/Makefile.in: top: (cd ..; $(MAKE) DIRS=$(DIR) TESTS=$(TESTS) all) Here the TESTS=$(TESTS) by default assigns "alltests" which is just one token, but the plural form of the variable suggests one could also set it to contain multiple test names and then the above line might fail. Regards and thanks, Rainer -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4311 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
What is the status of this bug? Will it be fixed in the next release (1.0.2f /1.1.0) ? Thanks, Torben -Ursprüngliche Nachricht- Von: Matt Caswell via RT [mailto:r...@openssl.org] Gesendet: Mittwoch, 3. Februar 2016 22:48 An: Dannhauer Torben <torben.dannha...@pmu.ac.at> Cc: openssl-dev@openssl.org Betreff: Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided On 03/02/16 19:43, Salz, Rich via RT wrote: >> The diff works perfectly on master, but exposed a new bug (bare snprintf). >> The following patch fixes it. I can make a PR (or add it to my >> existing PR #512) if you'd like. > > Please do as a separate PR. Thanks. I think Richard is already on the case, so no need for a PR. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
Thanks! -Ursprüngliche Nachricht- Von: Salz, Rich via RT [mailto:r...@openssl.org] Gesendet: Donnerstag, 11. Februar 2016 09:33 An: Dannhauer Torben <torben.dannha...@pmu.ac.at> Cc: openssl-dev@openssl.org Betreff: RE: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided > What is the status of this bug? Will it be fixed in the next release (1.0.2f > /1.1.0) ? yes -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
> What is the status of this bug? Will it be fixed in the next release (1.0.2f > /1.1.0) ? yes -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
> I verified the problem on both 1.0.2f and master: > > set LINK=/DEBUG > perl Configure VC-WIN64A > ms\do_win64a.bat > nmake -f ms\nt.make > > link /nologo /subsystem:console /opt:ref /debug > /out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp > LINK : fatal error LNK1181: cannot open input file 'link.obj' > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d' Patch is applied. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4289 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
On 03/02/16 19:43, Salz, Rich via RT wrote: >> The diff works perfectly on master, but exposed a new bug (bare snprintf). >> The following patch fixes it. I can make a PR (or add it to my existing PR >> #512) >> if you'd like. > > Please do as a separate PR. Thanks. I think Richard is already on the case, so no need for a PR. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
On 03/02/16 19:43, Salz, Rich via RT wrote: >> The diff works perfectly on master, but exposed a new bug (bare snprintf). >> The following patch fixes it. I can make a PR (or add it to my existing PR >> #512) >> if you'd like. > > Please do as a separate PR. Thanks. I think Richard is already on the case, so no need for a PR. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided (was: [OpenSSL Bug #2928])
This bug affects 1.0.2.f and supposedly also 1.1.0 alpha, I reported it already 3 years (!!) ago as Bug #2928 for OpenSSL 1.0.1c, but it was closed yesterday since 1.0.1 development is finished. Please find attached the Bug description again for OpenSSL 1.0.2f. I provide already a solution, so please apply the bug fix to trunk, 1.0.2 and 1.1.0 branches The bug is not obvious since only few people use the MSBuild System in this extend. However, it is clearly defined by MS how it's build system works and thus why OpenSSL building fails in certain conditions. -- BUG DESCRIPTION (Copied and updated from Bug #2928) -- Dear OpenSSL Team, I recently tried to build OpenSSL with Visual Studio and I discovered a very annoying but easy to fix bug: In the makefile created by Perl, the linker binary name is assigned to a variable named LINK. This variable $(LINK) is called to execute the linker call. This causes a serious collision with the MS Visual Studio build system which also relies on a variable named LINK: In Visual Studio, the compiler is called cl.exe and the linker is called link.exe. On invocation, they append the command line arguments to the environment variable identical to their name (if they exist). This allows to define "global" linker or compiler flags which are not part of the makefile. On the backside this also implies that a makefile must not use internal variable names identical to the build systems env-vars "LINK" and "CL". This error was observed with MS VS 2013 Update 5 but applies to older Visual Studios as well. ## Example with the CURRENT (WRONG) status # Build Environment (Visual Studio Command line): SET LINK= Makefile of OpenSSL SET LINK=link.exe SET LINKER_ARGS= The resulting linker call triggered by the makefile script is then: $(LINK) $(LINKER_ARGS) Which is extended by the MSVC build system to (because MSVC adds the content of the variable LINK after the linker command) $(LINK) $(LINK) $(LINKER_ARGS) and finally stripped to: link.exe link.exe This is a double invocation of link.exe which causes link to try linking itself, which of course fails. ### CORRECTED Example # Build Environment (Visual Studio Command line): SET LINK= Makefile: SET LINKER_BIN=link.exe SET LINKER_ARGS= The call should be: $(LINKER_BIN) $(LINKER_ARGS) Which would be extended by the MSVC build system to $(LINKER_BIN) $(LINK) $(LINKER_ARGS) and finally be stripped to: link.exe ==>This would be correct and working How to solve it: # - Never use the variables named LINK and CL inside the makefiles or their generator scripts. - Please call the binary variables different, e.g. LINKER_BIN and COMPILER_BIN - Adapt your build scripts to generate such corrected makefiles Thank you for your help Kind regards, Torben Dannhauer ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
> In the makefile created by Perl, the linker binary name is assigned to a > variable named LINK. This variable $(LINK) is called to execute the linker > call. > This causes a serious collision with the MS Visual Studio build system which > also relies on a variable named LINK: Are you invoking msbuild.exe to build openssl? The supported build instructions use nmake.exe directly on the generated makefiles. What is your build invocation? cheers, Joey ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
In the makefile created by Perl, the linker binary name is assigned to a variable named LINK. This variable $(LINK) is called to execute the linker call. This causes a serious collision with the MS Visual Studio build system which also relies on a variable named LINK: Are you invoking msbuild.exe to build openssl? The supported build instructions use nmake.exe directly on the generated makefiles. What is your build invocation? cheers, Joey ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #2654] [PATCH] support LDFLAGS in Makefiles
Sorry, nobody looked at this in years. It's too late for 1.0.1, it might be fixed in 1.0.2, and it's definiltey fixed in master. Closing ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
Zitat von Andy Polyakov via RT <r...@openssl.org>: > On 02/03/16 17:15, Joey Yandle via RT wrote: >>> In the makefile created by Perl, the linker binary name is assigned to a >>> variable named LINK. This variable $(LINK) is called to execute the >>> linker call. >>> This causes a serious collision with the MS Visual Studio build system >>> which also relies on a variable named LINK: >> >> Are you invoking msbuild.exe to build openssl? The supported build >> instructions use nmake.exe directly on the generated makefiles. >> >> What is your build invocation? > > That was my initial reaction too. The problem description sounds like as > if something else is being talked about. Indeed, it refers to SET > LINK=link.exe (there is not *SET* LINK in generated makefile), and you > can't help wondering how would such problem go unnoticed for such long > time. But as it turns out... Consider > > FOO=bar > > all: > echo %%FOO%% > > If passed to nmake, it prints "%FOO%" as long as there is no environment > variable named FOO. But as soon as you assign FOO variable prior > invoking nmake it prints "bar" irregardless[!] FOO's original value. > LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables > that can be used to specify kind of site-specific defaults. I find it > hard to imagine how LINK would be useful in general case, i.e. as > something that would be applicable to *all* linked binaries, but I > suppose one can't deny the option to do so. Out of curiosity what's > yours? And verify attached diff and report back. Hi, thanks for feedback, I use nmake as described in the instructions. Indeed, as I discovered and reported the bug 3 years ago, my first question was how such a problem was undiscovered for so a long time. At least now we are talking about it and agree we should fix it. Technical details: The env variable LINK is only evaluated by link.exe if it is set in the commandline (e.g. as required for compiling WinXP compatible binaries with VS 2012 and newer: setting another subsystem version) Since WinXP compiling is more than only setting linker flags, we simulate it by setting instead a empty LINK variable- the key aspect is that the COMMANDLINE has a set LINK variable , then the LINK variable is evaluated by link.exe and the error occurs. This happens because the OpenSSL makefile uses a also variable named LINK. To reproduce the error, open visual studio x64 commandline and enter: Set link="" perl Configure VC-WIN64A --prefix=c:\tmp_open_ssl_x64 ms\do_win64a nmake -f "ms\ntdll.mak" -> wait and see the linker step failing.. The provided patch is exactly what I did the last 3 years manually in the ntdll.mak makefile before starting the compilation. I would be very glad to see it marger into trunk. regards, Torben PS.: The full story to compile WinXP compatible binaries on commandline in VS2012 and newer is this: --- x86 - @set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE% @set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB% @set CL=/D_USING_V110_SDK71_;%CL% @set LINK=/SUBSYSTEM:CONSOLE,5.01 /MANIFEST %LINK% @echo Switched to XP target x86 --- x64 (WinXp x64 is quite rare) @set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE% @set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB% @set CL=/D_USING_V110_SDK71_;%CL% @set LINK=/SUBSYSTEM:CONSOLE,5.02 /MANIFEST %LINK% @echo Switched to XP target x64 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
I verified the problem on both 1.0.2f and master: set LINK=/DEBUG perl Configure VC-WIN64A ms\do_win64a.bat nmake -f ms\nt.make link /nologo /subsystem:console /opt:ref /debug /out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp LINK : fatal error LNK1181: cannot open input file 'link.obj' NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d' ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
I verified the problem on both 1.0.2f and master: set LINK=/DEBUG perl Configure VC-WIN64A ms\do_win64a.bat nmake -f ms\nt.make link /nologo /subsystem:console /opt:ref /debug /out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp LINK : fatal error LNK1181: cannot open input file 'link.obj' NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d' ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
Zitat von Andy Polyakov via RT < <mailto:r...@openssl.org> r...@openssl.org>: > On 02/03/16 17:15, Joey Yandle via RT wrote: >>> In the makefile created by Perl, the linker binary name is assigned >>> to a variable named LINK. This variable $(LINK) is called to execute >>> the linker call. >>> This causes a serious collision with the MS Visual Studio build >>> system which also relies on a variable named LINK: >> >> Are you invoking msbuild.exe to build openssl? The supported build >> instructions use nmake.exe directly on the generated makefiles. >> >> What is your build invocation? > > That was my initial reaction too. The problem description sounds like > as if something else is being talked about. Indeed, it refers to SET > LINK=link.exe (there is not *SET* LINK in generated makefile), and you > can't help wondering how would such problem go unnoticed for such long > time. But as it turns out... Consider > > FOO=bar > > all: > echo %%FOO%% > > If passed to nmake, it prints "%FOO%" as long as there is no > environment variable named FOO. But as soon as you assign FOO variable > prior invoking nmake it prints "bar" irregardless[!] FOO's original value. > LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables > that can be used to specify kind of site-specific defaults. I find it > hard to imagine how LINK would be useful in general case, i.e. as > something that would be applicable to *all* linked binaries, but I > suppose one can't deny the option to do so. Out of curiosity what's > yours? And verify attached diff and report back. Hi, thanks for feedback, I use nmake as described in the instructions. Indeed, as I discovered and reported the bug 3 years ago, my first question was how such a problem was undiscovered for so a long time. At least now we are talking about it and agree we should fix it. Technical details: The env variable LINK is only evaluated by link.exe if it is set in the commandline (e.g. as required for compiling WinXP compatible binaries with VS 2012 and newer: setting another subsystem version) Since WinXP compiling is more than only setting linker flags, we simulate it by setting instead a empty LINK variable- the key aspect is that the COMMANDLINE has a set LINK variable , then the LINK variable is evaluated by link.exe and the error occurs. This happens because the OpenSSL makefile uses a also variable named LINK. To reproduce the error, open visual studio x64 commandline and enter: Set link="" perl Configure VC-WIN64A --prefix=c:\tmp_open_ssl_x64 ms\do_win64a nmake -f "ms\ntdll.mak" -> wait and see the linker step failing.. The provided patch is exactly what I did the last 3 years manually in the ntdll.mak makefile before starting the compilation. I would be very glad to see it marger into trunk. regards, Torben PS.: The full story to compile WinXP compatible binaries on commandline in VS2012 and newer is this: --- x86 - @set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE% @set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB% @set CL=/D_USING_V110_SDK71_;%CL% @set LINK=/SUBSYSTEM:CONSOLE,5.01 /MANIFEST %LINK% @echo Switched to XP target x86 --- x64 (WinXp x64 is quite rare) @set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE% @set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH% @set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB% @set CL=/D_USING_V110_SDK71_;%CL% @set LINK=/SUBSYSTEM:CONSOLE,5.02 /MANIFEST %LINK% @echo Switched to XP target x64 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
And verify attached diff and report back. The diff works perfectly on master, but exposed a new bug (bare snprintf). The following patch fixes it. I can make a PR (or add it to my existing PR #512) if you'd like. diff --git a/test/ssltest.c b/test/ssltest.c index 5d6700e..9cd2a53 100644 --- a/test/ssltest.c +++ b/test/ssltest.c @@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int family, long count, if (BIO_do_accept(acpt) <= 0) goto err; -snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt)); +BIO_snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt)); client = BIO_new_connect(addr_str); BIO_set_conn_ip_family(client, family); ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
> And verify attached diff and report back. The diff works perfectly on master, but exposed a new bug (bare snprintf). The following patch fixes it. I can make a PR (or add it to my existing PR #512) if you'd like. diff --git a/test/ssltest.c b/test/ssltest.c index 5d6700e..9cd2a53 100644 --- a/test/ssltest.c +++ b/test/ssltest.c @@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int family, long count, if (BIO_do_accept(acpt) <= 0) goto err; -snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt)); +BIO_snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt)); client = BIO_new_connect(addr_str); BIO_set_conn_ip_family(client, family); ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
> The diff works perfectly on master, but exposed a new bug (bare snprintf). > The following patch fixes it. I can make a PR (or add it to my existing PR > #512) > if you'd like. Please do as a separate PR. Thanks. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided
On 02/03/16 17:15, Joey Yandle via RT wrote:
>> In the makefile created by Perl, the linker binary name is assigned to a
>> variable named LINK. This variable $(LINK) is called to execute the linker
>> call.
>> This causes a serious collision with the MS Visual Studio build system which
>> also relies on a variable named LINK:
>
> Are you invoking msbuild.exe to build openssl? The supported build
> instructions use nmake.exe directly on the generated makefiles.
>
> What is your build invocation?
That was my initial reaction too. The problem description sounds like as
if something else is being talked about. Indeed, it refers to SET
LINK=link.exe (there is not *SET* LINK in generated makefile), and you
can't help wondering how would such problem go unnoticed for such long
time. But as it turns out... Consider
FOO=bar
all:
echo %%FOO%%
If passed to nmake, it prints "%FOO%" as long as there is no environment
variable named FOO. But as soon as you assign FOO variable prior
invoking nmake it prints "bar" irregardless[!] FOO's original value.
LINK (as well as _LINK_) and CL (as well as _CL_) are indeed variables
that can be used to specify kind of site-specific defaults. I find it
hard to imagine how LINK would be useful in general case, i.e. as
something that would be applicable to *all* linked binaries, but I
suppose one can't deny the option to do so. Out of curiosity what's
yours? And verify attached diff and report back.
diff --git a/util/mk1mf.pl b/util/mk1mf.pl
index f9eeea8..506d491 100755
--- a/util/mk1mf.pl
+++ b/util/mk1mf.pl
@@ -646,7 +646,7 @@ EX_LIBS=$ex_libs
# The OpenSSL directory
SRC_D=$src_dir
-LINK=$link
+LINK_CMD=$link
LFLAGS=$lflags
RSC=$rsc
FIPSLINK=\$(PERL) util${o}fipslink.pl
diff --git a/util/pl/BC-32.pl b/util/pl/BC-32.pl
index 36ad682..364c4d4 100644
--- a/util/pl/BC-32.pl
+++ b/util/pl/BC-32.pl
@@ -142,7 +142,7 @@ ___
{
local($ex)=($target =~ /O_SSL/)?' $(L_CRYPTO)':'';
$ex.=' ws2_32.lib gdi32.lib';
- $ret.="\t\$(LINK) \$(MLFLAGS) $efile$target /def:ms/${Name}.def @<<\n \$(SHLIB_EX_OBJ) $objs $ex\n<<\n";
+ $ret.="\t\$(LINK_CMD) \$(MLFLAGS) $efile$target /def:ms/${Name}.def @<<\n \$(SHLIB_EX_OBJ) $objs $ex\n<<\n";
}
$ret.="\n";
return($ret);
@@ -156,7 +156,7 @@ sub do_link_rule
$file =~ s/\//$o/g if $o ne '/';
$n=($target);
$ret.="$target: $files $dep_libs\n";
- $ret.="\t\$(LINK) \$(LFLAGS) $files \$(APP_EX_OBJ), $target,, $libs\n\n";
+ $ret.="\t\$(LINK_CMD) \$(LFLAGS) $files \$(APP_EX_OBJ), $target,, $libs\n\n";
return($ret);
}
diff --git a/util/pl/Mingw32.pl b/util/pl/Mingw32.pl
index fe3fb27..55c85f6 100644
--- a/util/pl/Mingw32.pl
+++ b/util/pl/Mingw32.pl
@@ -98,7 +98,7 @@ sub do_link_rule
$file =~ s/\//$o/g if $o ne '/';
$n=($target);
$ret.="$target: $files $dep_libs\n";
- $ret.="\t\$(LINK) ${efile}$target \$(LFLAGS) $files $libs\n\n";
+ $ret.="\t\$(LINK_CMD) ${efile}$target \$(LFLAGS) $files $libs\n\n";
return($ret);
}
1;
diff --git a/util/pl/OS2-EMX.pl b/util/pl/OS2-EMX.pl
index 28cd116..92a332e 100644
--- a/util/pl/OS2-EMX.pl
+++ b/util/pl/OS2-EMX.pl
@@ -99,7 +99,7 @@ sub do_lib_rule
{
local($ex)=($target =~ /O_SSL/)?' $(L_CRYPTO)':'';
$ex.=' -lsocket';
- $ret.="\t\$(LINK) \$(SHLIB_CFLAGS) \$(MLFLAGS) $efile$target \$(SHLIB_EX_OBJ) \$(${Name}OBJ) $ex os2/${Name}.def\n";
+ $ret.="\t\$(LINK_CMD) \$(SHLIB_CFLAGS) \$(MLFLAGS) $efile$target \$(SHLIB_EX_OBJ) \$(${Name}OBJ) $ex os2/${Name}.def\n";
$ret.="\temximp -o $out_def/$name.a os2/${Name}.def\n";
$ret.="\temximp -o $out_def/$name.lib os2/${Name}.def\n\n";
}
@@ -113,7 +113,7 @@ sub do_link_rule
$file =~ s/\//$o/g if $o ne '/';
$n=($target);
$ret.="$target: $files $dep_libs\n";
- $ret.="\t\$(LINK) ${efile}$target \$(CFLAG) \$(LFLAGS) $files $libs\n\n";
+ $ret.="\t\$(LINK_CMD) ${efile}$target \$(CFLAG) \$(LFLAGS) $files $libs\n\n";
return($ret);
}
diff --git a/util/pl/VC-32.pl b/util/pl/VC-32.pl
index 73160e9..258b694 100644
--- a/util/pl/VC-32.pl
+++ b/util/pl/VC-32.pl
@@ -361,7 +361,7 @@ sub do_lib_rule
if ($fips && $target =~ /O_CRYPTO/)
{
$ret.="$target: $objs \$(PREMAIN_DSO_EXE)";
- $ret.="\n\tSET FIPS_LINK=\$(LINK)\n";
+ $ret.="\n\tSET FIPS_LINK=\$(LINK_CMD)\n";
$ret.="\tSET FIPS_CC=\$(CC)\n";
$ret.="\tSET FIPS_CC_ARGS=/Fo\$(OBJ_D)${o}fips_premain.obj \$(SHLIB_CFLAGS) -c\n";
$ret.="\tSET PREMAIN_DSO_EXE=\$(PREMAIN_DSO_EXE)\n";
@@ -375,7 +375,7 @@ sub do_lib_rule
else
{
$ret.="$target: $objs";
- $ret.="\n\t\$(LINK) \$(MLFLAGS) $efile$target $name @<<\n \$(SHLIB_EX_OBJ) $objs $ex \$(EX_LIBS)\n<<\n";
+ $ret.="\n\t\$(LINK_CMD) \$(MLF
[openssl-dev] [openssl.org #2928] openSSL 1.0.1c serious bug in Win32 makefiles, easy to fix: linker binary variable name LINK collides with buildsystem variable LINK . please rename
Sorry we didn't get to this sooner. We're only taking security fixes for 1.0.1 now. Please open a new ticket if this is still an issue with current releases. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
this can be closed now since d475b2a3bfde8d4aceefb41b21acc3711893d2a8 fixed it -mike signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
On Tue 16 Sep 2014 08:15:37 Andy Polyakov via RT wrote: This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- alphacpuid.s:alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null Can you confirm that preproc=/tmp/.$@.S in original snippet solves the problem? i don't understand what you mean. the code as written in the tree does not work with gcc. preproc will expand into /tmp/pid.alphacpuid.s, and since gcc will skip .s files with -E, you get no output. But if you name the file /tmp/pid.alphacpuid.s.S, then it should work. Because gcc driver looks at last extension, right? sorry, missed the .S suffix in all the noise :) i'd also highlight that relying on the pid # to give you a global unique tmp file is very very broken. it's easy for malicious people to clobber, and it's not even unique on modern Linux systems with pid namespaces. it should really just write it to $@.tmp instead and then do `mv $@ $@.tmp`. OK, preproc=$@.S then. Can you confirm that it works? that seems to work -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- alphacpuid.s: alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null Can you confirm that preproc=/tmp/.$@.S in original snippet solves the problem? i don't understand what you mean. the code as written in the tree does not work with gcc. preproc will expand into /tmp/pid.alphacpuid.s, and since gcc will skip .s files with -E, you get no output. But if you name the file /tmp/pid.alphacpuid.s.S, then it should work. Because gcc driver looks at last extension, right? i'd also highlight that relying on the pid # to give you a global unique tmp file is very very broken. it's easy for malicious people to clobber, and it's not even unique on modern Linux systems with pid namespaces. it should really just write it to $@.tmp instead and then do `mv $@ $@.tmp`. OK, preproc=$@.S then. Can you confirm that it works? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
On Fri 12 Sep 2014 09:44:59 Andy Polyakov via RT wrote: This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- alphacpuid.s: alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null Can you confirm that preproc=/tmp/.$@.S in original snippet solves the problem? i don't understand what you mean. the code as written in the tree does not work with gcc. preproc will expand into /tmp/pid.alphacpuid.s, and since gcc will skip .s files with -E, you get no output. i'd also highlight that relying on the pid # to give you a global unique tmp file is very very broken. it's easy for malicious people to clobber, and it's not even unique on modern Linux systems with pid namespaces. it should really just write it to $@.tmp instead and then do `mv $@ $@.tmp`. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
On Fri 12 Sep 2014 09:44:59 Andy Polyakov via RT wrote: This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- alphacpuid.s: alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null Can you confirm that preproc=/tmp/.$@.S in original snippet solves the problem? i don't understand what you mean. the code as written in the tree does not work with gcc. preproc will expand into /tmp/pid.alphacpuid.s, and since gcc will skip .s files with -E, you get no output. i'd also highlight that relying on the pid # to give you a global unique tmp file is very very broken. it's easy for malicious people to clobber, and it's not even unique on modern Linux systems with pid namespaces. it should really just write it to $@.tmp instead and then do `mv $@ $@.tmp`. -mike signature.asc Description: PGP signature
Re: [openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
Hi, This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- alphacpuid.s:alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null Can you confirm that preproc=/tmp/.$@.S in original snippet solves the problem? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1781] make makefiles traceable in 0.9.8i
Not doing this because of portability concerns. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2079] Mismatch in makefiles - compilation error on cygwin
builds now. time flies. or is it time heals all builds? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3333] [PATCH] Revert Make Makefiles OSF-make-friendly.
This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. When gcc is given a .s file and told to preprocess it, it outputs nothing. Since gcc targets are more common/important than OSF, revert it and let the original submitter sort out the problem. URL: https://bugs.gentoo.org/499086 --- crypto/Makefile | 4 +--- crypto/bn/Makefile| 4 +--- crypto/modes/Makefile | 5 + crypto/sha/Makefile | 4 +--- 4 files changed, 4 insertions(+), 13 deletions(-) diff --git a/crypto/Makefile b/crypto/Makefile index 0537913..6faa9c7 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -86,9 +86,7 @@ ia64cpuid.s: ia64cpuid.S;$(CC) $(CFLAGS) -E ia64cpuid.S $@ ppccpuid.s:ppccpuid.pl;$(PERL) ppccpuid.pl $(PERLASM_SCHEME) $@ pariscid.s:pariscid.pl;$(PERL) pariscid.pl $(PERLASM_SCHEME) $@ alphacpuid.s: alphacpuid.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) alphacpuid.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null subdirs: @target=all; $(RECURSIVE_MAKE) diff --git a/crypto/bn/Makefile b/crypto/bn/Makefile index 9eae43f..bb43706 100644 --- a/crypto/bn/Makefile +++ b/crypto/bn/Makefile @@ -136,9 +136,7 @@ ppc-mont.s: asm/ppc-mont.pl;$(PERL) asm/ppc-mont.pl $(PERLASM_SCHEME) $@ ppc64-mont.s: asm/ppc64-mont.pl;$(PERL) asm/ppc64-mont.pl $(PERLASM_SCHEME) $@ alpha-mont.s: asm/alpha-mont.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) asm/alpha-mont.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null # GNU make catch all %-mont.S: asm/%-mont.pl; $(PERL) $ $(PERLASM_SCHEME) $@ diff --git a/crypto/modes/Makefile b/crypto/modes/Makefile index b8cfa71..b0d5b9f 100644 --- a/crypto/modes/Makefile +++ b/crypto/modes/Makefile @@ -55,10 +55,7 @@ aesni-gcm-x86_64.s: asm/aesni-gcm-x86_64.pl ghash-sparcv9.s: asm/ghash-sparcv9.pl $(PERL) asm/ghash-sparcv9.pl $@ $(CFLAGS) ghash-alpha.s: asm/ghash-alpha.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) asm/ghash-alpha.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) - + $(PERL) $ | $(CC) -E - | tee $@ /dev/null ghash-parisc.s:asm/ghash-parisc.pl $(PERL) asm/ghash-parisc.pl $(PERLASM_SCHEME) $@ diff --git a/crypto/sha/Makefile b/crypto/sha/Makefile index 64eab6c..63fba69 100644 --- a/crypto/sha/Makefile +++ b/crypto/sha/Makefile @@ -60,9 +60,7 @@ sha256-armv4.S: asm/sha256-armv4.pl $(PERL) $ $(PERLASM_SCHEME) $@ sha1-alpha.s: asm/sha1-alpha.pl - (preproc=/tmp/.$@; trap rm $$preproc INT; \ - $(PERL) asm/sha1-alpha.pl $$preproc \ - $(CC) -E $$preproc $@ rm $$preproc) + $(PERL) $ | $(CC) -E - | tee $@ /dev/null # Solaris make has to be explicitly told sha1-x86_64.s: asm/sha1-x86_64.pl; $(PERL) asm/sha1-x86_64.pl $(PERLASM_SCHEME) $@ -- 1.9.2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2988] Makefiles should (usually) remove target before re-generating
Yes, it predates the latest release. I thin in general it's like a makefile hygiene thing -- if files are read-only, but can be created, then the target needs to be removed first. -- Principal Security Engineer Akamai Technology Cambridge, MA :��IϮ��r�m (Z+�7�zZ)���1���x ��hW^��^��%�� ��jם.+-1�ځ��j:+v���h�
RE: [openssl.org #2988] Makefiles should (usually) remove target before re-generating
Yes, it predates the latest release. I thin in general it's like a makefile hygiene thing -- if files are read-only, but can be created, then the target needs to be removed first. -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2988] Makefiles should (usually) remove target before re-generating
On Thu Feb 14 14:24:18 2013, rs...@akamai.com wrote: We extract a tarball and make everything read-only. Sometimes an item in the distribution gets re-made. This can fail because of permissions. So, on platforms where this would happen, we'd like to remove the file first. I wasn't advocating to remove them from the distro, I understand we need to be kind to our crippled (cough vms:) brethren. Is this more clear? Did you have any problems before OpenSSL 1.0.1d? I think this is an artifact of how I generated the release tarballs with git: this is only the second one I've done and I'm still tweaking it a bit to handle some of the differences compared to cvs. I'll modify the process I'm using to ensure the timestamps of the auto built files are reasonable before creating the tarballs. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2988] Makefiles should (usually) remove target before re-generating
On Thu Feb 14 04:35:05 2013, rs...@akamai.com wrote: Unfortunately some platforms can't automatically build the files e.g. WIN32, VMS. Okay, so those targets shouldn't get invoked? Or are you saying that you WANT the build to fail on those platforms? Ah so you're saying the files would be retained in tarballs and under version control just deleted before being recreated? [I might have misinterpeted this. Sometimes it is suggested that all auto generated files should be deleted from the tarballs... which we can't do for the reasons stated] # objects.pl both reads and writes obj_mac.num obj_mac.h: objects.pl objects.txt obj_mac.num + $(RM) obj_mac.num $@ $(PERL) objects.pl objects.txt obj_mac.num $@ @sleep 1; touch obj_mac.h; sleep 1 + chmod 444 obj_mac.num $@ Deleting obj_mac.num is a bad idea. It contains the NID values which are added to over time. If you delete that file the recreated version is almost certain to have a different NID assignment which breaks binary compatibility. Okay. Then would you be interested in patch to objects.pl and the Makefile that created obj_mac.new and the Makefile replaced the file? Can you explain the problem with the current system? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2988] Makefiles should (usually) remove target before re-generating
We extract a tarball and make everything read-only. Sometimes an item in the distribution gets re-made. This can fail because of permissions. So, on platforms where this would happen, we'd like to remove the file first. I wasn't advocating to remove them from the distro, I understand we need to be kind to our crippled (cough vms:) brethren. Is this more clear? -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2988] Makefiles should (usually) remove target before re-generating
Some targets need to be removed before rebuilding them: In apps/Makefile, add $(RM) $@ after progs.h line In crypt/bn/Makefile, something like this: bn_prime.h: bn_prime.pl $(RM) $@ $(PERL) bn_prime.pl $@ Chmod 444 $@ In crypto/objects/Makefile: obj_dat.h: obj_dat.pl obj_mac.h + $(RM) $@ $(PERL) obj_dat.pl $@ + chmod 444 $@ # objects.pl both reads and writes obj_mac.num obj_mac.h: objects.pl objects.txt obj_mac.num + $(RM) obj_mac.num $@ $(PERL) objects.pl objects.txt obj_mac.num $@ @sleep 1; touch obj_mac.h; sleep 1 + chmod 444 obj_mac.num $@ In crypto/evp/Makefile: links: @$(PERL) $(TOP)/util/mklink.pl ../../include/openssl $(EXHEADER) @$(PERL) $(TOP)/util/mklink.pl ../../test $(TEST) + $(RM) ../../test/$(TESTDATA) [ ! -f $(TESTDATA) ] || cp $(TESTDATA) ../../test + chmod 444 ../../test/$(TESTDATA) @$(PERL) $(TOP)/util/mklink.pl ../../apps $(APPS) -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2988] Makefiles should (usually) remove target before re-generating
On Wed Feb 13 20:28:12 2013, rs...@akamai.com wrote: Some targets need to be removed before rebuilding them: Unfortunately some platforms can't automatically build the files e.g. WIN32, VMS. Also: # objects.pl both reads and writes obj_mac.num obj_mac.h: objects.pl objects.txt obj_mac.num + $(RM) obj_mac.num $@ $(PERL) objects.pl objects.txt obj_mac.num $@ @sleep 1; touch obj_mac.h; sleep 1 + chmod 444 obj_mac.num $@ Deleting obj_mac.num is a bad idea. It contains the NID values which are added to over time. If you delete that file the recreated version is almost certain to have a different NID assignment which breaks binary compatibility. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2988] Makefiles should (usually) remove target before re-generating
Unfortunately some platforms can't automatically build the files e.g. WIN32, VMS. Okay, so those targets shouldn't get invoked? Or are you saying that you WANT the build to fail on those platforms? # objects.pl both reads and writes obj_mac.num obj_mac.h: objects.pl objects.txt obj_mac.num + $(RM) obj_mac.num $@ $(PERL) objects.pl objects.txt obj_mac.num $@ @sleep 1; touch obj_mac.h; sleep 1 + chmod 444 obj_mac.num $@ Deleting obj_mac.num is a bad idea. It contains the NID values which are added to over time. If you delete that file the recreated version is almost certain to have a different NID assignment which breaks binary compatibility. Okay. Then would you be interested in patch to objects.pl and the Makefile that created obj_mac.new and the Makefile replaced the file? -- Principal Security Engineer Akamai Technology Cambridge, MA Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2928] openSSL 1.0.1c serious bug in Win32 makefiles, easy to fix: linker binary variable name LINK collides with buildsystem variable LINK . please rename
Dear OpenSSL Team, I recently tried to build OpenSSL with Visual Studio and I discovered a very annoying but easy to fix bug: In the makefile created by perl, the linker binary name is assigned to a variable named LINK. This variable $(LINK) is called to execute the linker call. This causes a serious collision with the MS Visual Studio build system which also relies on the variable LINK: In Visual Studion, the compiler ist called cl.exe and the linker is called link.exe. On invocation, they append the command line arguments to the environment variable identical to their name (if they exist). This allows to define global linker or compiler flags which are not part of the makefile. On the backside this also implies that a makefile must not use internal variable names identical tot he envVars LINK and CL. This error was observed with MS VS2012 Update 1 but applies to older Visual Studios as well. ## Example with the CURRENT (WRONG) status # Environment: SET LINK=my global linker flags Makefile SET LINK=link.exe SET LINKER_ARGS=my linker args The call is: $(LINK) $(LINKER_ARGS) Which is extened by the MSVC build system to (because MSVC adds the content oft he variable LINK after the linker command) $(LINK) $(LINK) $(LINKER_ARGS) and finally stripped to: link.exe link.exe my linker args è This is a double invokation of linkexe which causes link to try linking itself, which of course fails. ### CORRECTED Example # Environment: SET LINK=my global linker flags Makefile: SET LINKER_BIN=link.exe SET LINKER_ARGS=my linker flags The call should be: $(LINKER_BIN) $(LINKER_ARGS) Which would be extened by the MSVC build system to $(LINKER_BIN) $(LINK) $(LINKER_ARGS) and finally be stripped to: link.exe my global linker flags my linker flags ==This would be cortect and working How to solve it: # - Never use the variables named LINK and CL inside the makefiles or their generator scripts. - Please call the binary variables different, e.g. LINKER_BIN and COMPILER_BIN - Adapt your build scritps to generate such corrected makefiles Thank you for your help Torben Dannhauer Dear OpenSSL Team,I recently tried to build OpenSSL with Visual Studio and I discovered a very annoying but easy to fix bug: In the makefile created by perl, the linker binary name is assigned to a variable named LINK. This variable $(LINK) is called to execute the linker call.This causes a serious collision with the MS Visual Studio build system which also relies on the variable LINK:In Visual Studion, the compiler ist called cl.exe and the linker is called link.exe.On invocation, they append the command line arguments to the environment variable identical to their name (if they exist). This allows to define global linker or compiler flags which are not part of the makefile.On the backside this also implies that a makefile must not use internal variable names identical tot he envVars LINK and CL.This error was observed with MS VS2012 Update 1 but applies to older Visual Studios as well.## Example with the ?CURRENT (WRONG) status #Environment:SET LINK=my global linker flagsMakefileSET LINK=link.exeSET LINKER_ARGS=my linker argsThe call is:$(LINK) $(LINKER_ARGS) Which is extened by the MSVC build system to (because MSVC adds the content oft he variable LINK after the linker command)$(LINK) $(LINK) $(LINKER_ARGS) and finally stripped to:??? link.exe link.exe my linker args? This is a double invokation of linkexe which causes link to try linking itself, which of course fails.### ?CORRECTED Example #Environment:SET LINK=my global linker flagsMakefile:SET LINKER_BIN=link.exeSET LINKER_ARGS=my linker flagsThe call should be:$(LINKER_BIN) $(LINKER_ARGS) Which would be extened by the MSVC build system to $(LINKER_BIN) $(LINK) $(LINKER_ARGS) and finally be stripped to:??? link.exe my global linker flags my linker flags?This would be cortect and working How to solve it: #- Never use the variables named LINK and CL inside the makefiles or their generator scripts.- Please call the binary variables different, e.g. ?LINKER_BIN and COMPILER_BIN- Adapt your build scritps to generate such corrected makefilesThank you for your helpTorben Dannhauer
[openssl.org #2654] [PATCH] support LDFLAGS in Makefiles
Attached patch will allow passing the LDFLAGS variable to the build,
making it possible to pass individual linker flags if wanted. Patch is
taken from Gentoo Linux.
It'd be great if this could be incorporated before 1.0.1
http://bugs.gentoo.org/327421
--- Makefile.org
+++ Makefile.org
@@ -189,6 +189,7 @@
MAKEDEPEND='{TOP}/util/domd {TOP} -MD $(MAKEDEPPROG)' \
DEPFLAG='-DOPENSSL_NO_DEPRECATED $(DEPFLAG)' \
MAKEDEPPROG='$(MAKEDEPPROG)' \
+ LDFLAGS='${LDFLAGS}'\
SHARED_LDFLAGS='$(SHARED_LDFLAGS)' \
KRB5_INCLUDES='$(KRB5_INCLUDES)' LIBKRB5='$(LIBKRB5)' \
ZLIB_INCLUDE='$(ZLIB_INCLUDE)' LIBZLIB='$(LIBZLIB)' \
--- Makefile.shared
+++ Makefile.shared
@@ -153,7 +153,7 @@
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \
SHAREDFLAGS=$(CFLAGS) $(SHARED_LDFLAGS) -shared -Wl,-Bsymbolic -Wl,-soname=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX
-DO_GNU_APP=LDFLAGS=$(CFLAGS) -Wl,-rpath,$(LIBRPATH)
+DO_GNU_APP=LDFLAGS=$(LDFLAGS) $(CFLAGS) -Wl,-rpath,$(LIBRPATH)
#This is rather special. It's a special target with which one can link
#applications without bothering with any features that have anything to
signature.asc
Description: PGP signature
Re: [openssl.org #2079] Mismatch in makefiles - compilation error on cygwin
Stephen Henson via RT wrote: [ava...@hot.ee - Mon Oct 26 09:16:28 2009]: there is a problem in the Makefiles that precludes correct compilation of openSSL, at least on cygwin. The problem is present in 1.0.0-beta3 as well. That's strange: I downloaded and installed Cygwin and I don't get any errors when I do a make or a make test. A symbolic link is created from rc5test.c to dummytest.c just fine. I tested it again and it depends on how you untar the archive. If you untar it with cygwin tools like tar -xvf then the links from the archive are recreated properly and compilation goes through fine. If you use a windows tool like 7zip, it creates empty files instead of symbolic links, in which case compilation fails, as those files are never replaced by actual links before there is an attempt to compile them. How did you untar the archive? Basically the compilation currently relies on the links being there from the start, which I think is wrong, given that there exists a rule to create them (it just doesn't get invoked). Once again, to recreate: - untar the source using a windows tool like 7zip. A file like tests/rc5test.c shall be something other than a valid cygwin link after that. - ./config make - this hits an error. Best, Misha __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2079] Mismatch in makefiles - compilation error on cygwin
Stephen Henson via RT wrote: [ava...@hot.ee - Mon Oct 26 09:16:28 2009]: there is a problem in the Makefiles that precludes correct compilation of openSSL, at least on cygwin. The problem is present in 1.0.0-beta3 as well. That's strange: I downloaded and installed Cygwin and I don't get any errors when I do a make or a make test. A symbolic link is created from rc5test.c to dummytest.c just fine. I tested it again and it depends on how you untar the archive. If you untar it with cygwin tools like tar -xvf then the links from the archive are recreated properly and compilation goes through fine. If you use a windows tool like 7zip, it creates empty files instead of symbolic links, in which case compilation fails, as those files are never replaced by actual links before there is an attempt to compile them. How did you untar the archive? Basically the compilation currently relies on the links being there from the start, which I think is wrong, given that there exists a rule to create them (it just doesn't get invoked). Once again, to recreate: - untar the source using a windows tool like 7zip. A file like tests/rc5test.c shall be something other than a valid cygwin link after that. - ./config make - this hits an error. Best, Misha __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2079] Mismatch in makefiles - compilation error on cygwin
From: Misha Aizatulin via RT r...@openssl.org I tested it again and it depends on how you untar the archive. If you untar it with cygwin tools like tar -xvf then the links from the archive are recreated properly and compilation goes through fine. If you use a windows tool like 7zip, it creates empty files instead of symbolic links, in which case compilation fails, as those files are never replaced by actual links before there is an attempt to compile them. How did you untar the archive? [...] These symbolic links are also a nuisance on VMS, where old VMS versions (or old file systems under new VMS versions) can't do them. A while ago, I modified some VMS builders to go get these files where they live, ignoring any symbolic links which may or may not work. (Changes not adopted yet, so far as I know. Current VMS builders tend to copy these files around, which is even more annoying.) Why have these links? Is it really all that much more convenient to have a local link to a distant file when one could simply use the distant file? Or is there some compiler on a UNIX(-like) system which can't compile a distant source file into a local object/executable? (Surely some lame/goofy rule could be devised, even in that situation.) Steven M. Schweda s...@antinode-info 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2079] Mismatch in makefiles - compilation error on cygwin
[ava...@hot.ee - Mon Oct 26 09:16:28 2009]: there is a problem in the Makefiles that precludes correct compilation of openSSL, at least on cygwin. The problem is present in 1.0.0-beta3 as well. In the top-level Makefile the value SDIRS does not contain rc5. As a result, make links does not create a link to rc5test.c in test. However the Makefile in test tries to compile rc5test.c during make all in test. The result is that when doing make on top level, we hit a failure: The top level Makefile doesn't contain rc5 in SDIRS on any platform unless rc5 is enabled so that isn't the problem. Symbolic links (or copies on some platforms) are made by Makefile/test using util/point.sh I just tested this in mingw and it works fine. Presumably symbolic links don't work under Cygwin? If so I'd suggest modifying util/point.sh so it also checks for Cygwin. If that works let me know and I'll commit this to CVS. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2079] Mismatch in makefiles - compilation error on cygwin
there is a problem in the Makefiles that precludes correct compilation
of openSSL, at least on cygwin. The problem is present in 1.0.0-beta3 as
well.
In the top-level Makefile the value SDIRS does not contain rc5. As a
result, make links does not create a link to rc5test.c in test.
However the Makefile in test tries to compile rc5test.c during make
all in test. The result is that when doing make on top level, we hit
a failure:
gcc -I.. -I../include -I../fips -DOPENSSL_THREADS -DDSO_DLFCN
-DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM
-DMD5_ASM -DRMD160_ASM -DAES_ASM -c -o rc5test.o rc5test.c
make[2]: Entering directory
`/c/docs/verification/openssl/openssl-0.9.8j/test'
( :; LIBDEPS=${LIBDEPS:--L.. -lssl -L.. -lcrypto };
LDCMD=${LDCMD:-gcc}; LDFLAGS=${LDFLAGS:--DOPENSSL_THREADS
-DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3
-march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
-DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM}; LIBPATH=`for x in
$LIBDEPS; do if echo $x | grep '^ *-L' /dev/null 21; then echo $x |
sed -e 's/^ *-L//'; fi; done | uniq`; LIBPATH=`echo $LIBPATH | sed -e
's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD}
${LDFLAGS} -o ${APPNAME:=rc5test.exe} rc5test.o ${LIBDEPS} )
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab):
undefined reference to `_winm...@16'
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
perl Configure CFLAG output does not match makefiles
Apparently not all of the CFLAGs which are generated by perl Configure zlib --with-krb5-flavor=MIT VC-WIN32 are moved to the resulting ms\*.mak files. In particular, -DZLIB -DKRB5_MIT -DOPENSSL_THREADS -DDSO_WIN32 are not moved although there could be more items. util/mk1mf.pl most likely needs to be updated to understand all of the new options added Configure. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED]OpenSSL. Interfaces with OpenSSH __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL Makefiles - SUGGESTION
On Thu, Feb 07, 2002 at 07:17:50AM -0500, Saju Paul Panikulam wrote: It would be nice to have a paragraph in the Makefiles to remove the TAB (^I) characters from the OpenSSL source and header files. The debugger on the platform that we use does not handle the TABs very well. Had to write a little script to remove them. We used expand but any editor (ex, ed, sed) should be able to do the same job. I don't think we should further complicate the Makefiles by including workarounds for this kind of problems with broken software. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL Makefiles - SUGGESTION
It would be nice to have a paragraph inthe Makefiles to remove the TAB (^I) characters from the OpenSSL source and header files. The debugger on the platform thatwe usedoes not handle the TABs very well.Had to write a little script toremove them.We used expand but anyeditor (ex, ed, sed) shouldbe able to do the same job. Tx
Re: Makefiles
Quoting Craig Southeren ([EMAIL PROTECTED]): On Mon, 08 Feb 1999 02:27:31 + Dr Stephen Henson [EMAIL PROTECTED] wrote: The main problem with using Cygnus gcc is the license is incompatible with the OpenSSL one: specifically the underlying SSLeay license which we can't change even if we wanted to. Hear, hear. As much as the existing configuration system is a pain, please realise that not everyone uses Unix and Perl, and that not everyone likes the restrictions of the GPL. IMHO, the a large part of the success of OpenSSL lies in the fact that is *can* be used in commercial products in lieu of proprietary solutions. Please don't compromise this. Can you elaborate, specifically, about how the license of the various programs mentioned prevent their use for the present purpose? You really must support this claim. -josh __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Makefiles
Craig Southeren wrote: On Monday, 8 February 1999 19:46, Lutz Behnke [SMTP:[EMAIL PROTECTED]] wrote: As much as the existing configuration system is a pain, please realise that not everyone uses Unix and Perl, and that not everyone likes the restrictions of the GPL. (sorry to hear that B-( ) IMHO, the a large part of the success of OpenSSL lies in the fact that is *can* be used in commercial products in lieu of proprietary solutions. Please don't compromise this. I do not see any problem with this by using the GNU tools to work this. GPL specificly does _not_ apply to 'documents' created with them. That is why you can create proprietary products using the gcc. In a general sense, the GPL can apply to anything. Obviously gcc does not automatically apply the GPL to code that is compiled using itself. But there is no reason why it couldn't - in fact it has always suprised my that Stallman didn't apply that restriction to gcc. For the same reason that he put the glibc and some other libraries under the Lesser GPL: exposure. The newly developed GNU system could only compete with the UNIX variants of the time if it was better in performance and stability. The full statement by him is on the web site and was in a recent article on gnu.announce In any case, if all of the files produced by autoconf are GPL-free then there isn't a problem as far as the license is concerned. quoting from the Automake manual: 21 Distributing `Makefile.in's Automake places no restrictions on the distribution of the resulting `Makefile.in's. We still encourage software authors to distribute their work under terms like those of the GPL, but doing so is not required to use Automake. Some of the files that can be automatically installed via the --add-missing switch do fall under the GPL; examine each file to see. Due to the underlying license from Eric and Tim we cannot change the license. But we can use Autoconf and Libtool all we want without restricting the license of the library. It those tools that you cannot include in your proprietary software. That is why the distribution needs to include the 'configure' and not just configure.in and autoconf. But all you have to do is install the needed tools, that in no shape or form limit you use with proprietary software, with one small exception: you cannot link or otherwise _include_ GPLed stuff in you program. Note that the GPL can just as easily apply to perl scripts or shell scripts as well as C code. Umm, yes. And the point is? since the library is explicitly exlcuded from being put under the GPL all derivative works may not be put under GPL either. And even I would like to do so, I would advise agains making things even more complex by putting new parts under license differing from the old stuff. And does autoconf run under Windows yet? Does anybody know? As far as I understood from the mozilla build that is exactly what they are working on, since the mozilla team has the exact same problem as we have and a somewhat bigger code base. They decided that those who want to build mozilla may be asked to install the cygwin tools and use the bash/automake/autoconf suite. The nessecary m4 macros for VC support are being written. philosophy/political IMHO may those that want to use a piece of open source be asked to adopt the build strategy of the community that produced it. All those that are _able_ to make use of uncompiled library source should be able to install cygwin32. This is advantage for all, since the 'sufficient eyes make problems trivial' approach only works in large numbers. So we should use the same basic configure/make mechanism as mozilla and an endless list of GNU tools. /philosophy/political (Why should you listen to this? What merit do I have with regards to OpenSSL? none yet!) mfg lutz -- *** Lutz Behnke Tel.: 040 / 766 29 1423 TC TrustCenter for Security Fax.: 040 / 766 29 577 in Data Networks GmbH email: [EMAIL PROTECTED] Am Werder 1 21073 Hamburg, Germany S/MIME Cryptographic Signature
Re: Makefiles
Josh MacDonald wrote: Can you elaborate, specifically, about how the license of the various programs mentioned prevent their use for the present purpose? You really must support this claim. My original comment about license problems refererred to Cygnus gcc library and OpenSSL. Unlike other ports of gcc the library is covered by GPL *not* the library license as is usually the case. This means that anything linked with the Cygnus Win32 library must be placed under GPL. If you check out the OpenSSL license (and the original SSLeay license) it says quite explicitly: "The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.]" This can't be changed even if we wanted to. If the Cygnus library has changed and this is no longer the case then this isn't a problem any more. The comment does not apply to autoconf et al. If that could be made to work on all platforms currently supported using, for example, VC++ under Win32 and Win 3.1 then fair enough. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Makefiles
Ben Laurie [EMAIL PROTECTED] writes: Ulf Möller wrote: When libcrypto.a is deleted and then re-made, the Makefiles only put those files into the new library which had to be newly built. A better way would be to create an .a file in each subdirectory and create a new libcrypto.a out of them whenever necessary. It will probably be somewhat slower, but at least the library is always consistent. Can that be done, generally? I've never tried to make a library out of other libraries. You have to extract the object files from the library, and create a new library from these object files plus any additional ones. -Tom __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Makefiles
Well, not today. There is one problem that stands in the way of using automake, which is the layout of the files in the package. I only know how to have libraries built for which all source files reside in the same directory. This is more or less the same problem I've seen discussed here for the creation of dynamic libs on UNIX. it acceptable to either a) rearrange the source tree b) require linking against more, finer grained, libraries If either of these is okay, then using the GNU tools will be quite easy. It appears to me that using Cliff's multi-library consolidation would be the way to go in this direction. (Another problem I would note with respect to Josh posting a patch is that I think he is a US citizen.) -Sameer, who is really just an agent of the BXA. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Makefiles
Can that be done, generally? I've never tried to make a library out of other libraries. We do this using a script we wrote called amallibs on UNIX, and I believe that one of our projects uses the MS library maintenance tool to do this agglomeration also. All you have to do is keep the filenames unique! I'll try to get our amallibs script released, although it's shell not perl so you'd probably prefer to write your own. All it does is "ar x" all the files into a temp dir, "chmod -w" on each set to catch duplicate filenames, and "ar cq" to create the new lib. -- Clifford Heathhttp://www.osa.com.au/~cjh Open Software Associates Limited mailto:[EMAIL PROTECTED] 29 Ringwood Street / PO Box 4414 Phone +613 9871 1694 Ringwood VIC 3134 AUSTRALIA Fax+613 9871 1711 Deploying Solutions to the Enterprise __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Makefiles
Josh MacDonald wrote: To solve your Makefile problems, I think you should all realize that the GNU autoconf solution, along with automake and libtool, have improved dramatically in the last couple of years. With libtool, your shared library problems are solved completely, with no effort, and it is supported by the the Cygnus utilities on Windows. What is the percieved value of perl, if I may ask? Would it work using VC++ under Windows as the compiler, that is Win 3.1 as well as Win32? Yes there is some demand to still support Win 3.1. The main problem with using Cygnus gcc is the license is incompatible with the OpenSSL one: specifically the underlying SSLeay license which we can't change even if we wanted to. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Makefiles
On Mon, 08 Feb 1999 02:27:31 + Dr Stephen Henson [EMAIL PROTECTED] wrote: Josh MacDonald wrote: To solve your Makefile problems, I think you should all realize that the GNU autoconf solution, along with automake and libtool, have improved dramatically in the last couple of years. With libtool, your shared library problems are solved completely, with no effort, and it is supported by the the Cygnus utilities on Windows. What is the percieved value of perl, if I may ask? Would it work using VC++ under Windows as the compiler, that is Win 3.1 as well as Win32? Yes there is some demand to still support Win 3.1. The main problem with using Cygnus gcc is the license is incompatible with the OpenSSL one: specifically the underlying SSLeay license which we can't change even if we wanted to. Hear, hear. As much as the existing configuration system is a pain, please realise that not everyone uses Unix and Perl, and that not everyone likes the restrictions of the GPL. IMHO, the a large part of the success of OpenSSL lies in the fact that is *can* be used in commercial products in lieu of proprietary solutions. Please don't compromise this. Regards, Craig Southeren --- Equivalence Pty Ltd Home of FireDoor, MibMaster PhonePatch For Open Source H.323 - see http://www.openh323.org Email: [EMAIL PROTECTED] Web: http://www.equival.com.au Fax: +61 2 4368 1395Voice: +61 2 4368 2118 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
