[Mingw-users] How to build *shared* openssl libraries in msys shell
Sisyphus
----- Original Message -----
From: "Sisyphus" <sisy...@optusnet.com.au>
To: "openssl" <openss...@openssl.org>
Sent: Friday, October 29, 2010 12:43 PM
Subject: [MinGW] undefined reference to `ERR_unload_strings'
Hi,
I posted this to the openssl mailing list a couple of days back, but have
received no repsonses.
> Building recent openssl (0.9.8n, 0.9.8o) from source in the MSYS shell
> with the MinGW port of gcc-3.4.5.
>
> When trying to build a shared library (dll), I do './config --shared &&
> make'. Everything is fine until, during the 'make' stage, we switch to the
> 'engines' directory:
>
> make[1]: Entering directory `/c/_32/comp/openssl-0.9.8o/engines'
>
> [snip - e_4758cca.o, e_aep.o, e_atalla.o, e_cswift.o, e_gmp.o, e_chil.o,
> e_nuron.o, e_sureware.o, e_ubsec.o and e_capi.o were successfully
> compiled at this stage]
>
> make[2]: Entering directory `/c/_32/comp/openssl-0.9.8o/engines'
> e_4758cca.o:e_4758cca.c:(.text+0x40): undefined reference to
> `ERR_unload_strings'
> e_4758cca.o:e_4758cca.c:(.text+0x53): undefined reference to
> `ERR_unload_strings'
> e_4758cca.o:e_4758cca.c:(.text+0x75): undefined reference to `CRYPTO_free'
> e_4758cca.o:e_4758cca.c:(.text+0xb5): undefined reference to `DSO_load'
>
> [snip other similar errors]
>
> e_4758cca.o:e_4758cca.c:(.text+0x1724): undefined reference to
> `ENGINE_set_cmd_defns'
> e_4758cca.o:e_4758cca.c:(.text+0x173e): undefined reference to
> `ERR_get_next_error_library'
> e_4758cca.o:e_4758cca.c:(.text+0x176a): undefined reference to
> `ERR_load_strings'
> e_4758cca.o:e_4758cca.c:(.text+0x177d): undefined reference to
> `ERR_load_strings'
> e_4758cca.o:e_4758cca.c:(.text+0x14fd): undefined reference to
> `CRYPTO_free'
> collect2: ld returned 1 exit status
> make[2]: *** [link_o.cygwin] Error 1
> make[2]: Leaving directory `/c/_32/comp/openssl-0.9.8o/engines'
> make[1]: *** [lib] Error 2
> make[1]: Leaving directory `/c/_32/comp/openssl-0.9.8o/engines'
> make: *** [build_engines] Error 1
>
> Any idea as to what's going wrong here ?
On looking at the engines/Makefile, I'm guessing that the error is in
response to this section of that Makefile:
###################################
all: lib
lib: $(LIBOBJ)
@if [ -n "$(SHARED_LIBS)" ]; then \
set -e; \
for l in $(LIBNAMES); do \
$(MAKE) -f ../Makefile.shared -e \
LIBNAME=$$l LIBEXTRAS=e_$$l.o \
LIBDEPS='-L.. -lcrypto $(EX_LIBS)' \
link_o.$(SHLIB_TARGET); \
done; \
else \
$(AR) $(LIB) $(LIBOBJ); \
$(RANLIB) $(LIB) || echo Never mind.; \
fi; \
touch lib
###################################
But I don't know what's going wrong there. (The file ../libcrypto.a, exists
and seems to me that it should be capable of resolving those references.)
Anyone here with experience/insights regarding this issue ?
Cheers,
Rob
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW...@lists.sourceforge.net
This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Roumen Petrov
> ----- Original Message -----
> From: "Sisyphus"<sisy...@optusnet.com.au>
> To: "openssl"<openss...@openssl.org>
> Sent: Friday, October 29, 2010 12:43 PM
> Subject: [MinGW] undefined reference to `ERR_unload_strings'
>
>
> Hi,
>
> I posted this to the openssl mailing list a couple of days back, but have
> received no repsonses.
>
>> Building recent openssl (0.9.8n, 0.9.8o) from source in the MSYS shell
>> with the MinGW port of gcc-3.4.5.
>>
>> When trying to build a shared library (dll), I do './config --shared&&
>> make'. Everything is fine until, during the 'make' stage, we switch to the
>> 'engines' directory:
>>
Build with perl script are only supported for 1.+ versions (ref. to
openssl request tracker and development mail lists).
Versions before should use "one makefile build".
You could build based on perl (configure) with attached patch
"openssl-0.9.8o.patch-MINGW.gz". This is updated version of the patch
posted in openssl request tracker. I use it to cross-build.
For the complete patch for MSYS environment at least an additional
change is required. I can not remember which file must be updated - it
is a check for symlink support and MSYS perl return yes. This is
corrected in 1.* openssl versions.
Why do not just switch to 1.+ version ?
Roumen
Sisyphus
----- Original Message -----
From: "Roumen Petrov"
> Build with perl script are only supported for 1.+ versions (ref. to
> openssl request tracker and development mail lists).
> Versions before should use "one makefile build".
Interestingly, there's no problem building a static openssl (so long as one
uses a native Win32 perl, and not the msys perl ..... which is something
contrary to usual advice).
And I found a note I'd left for myself that indicated I had built 0.9.8n
dynamically:
[quote]
To build a dynamic openssl-0.9.8n I ran './config shared'.
Then remove the 'static' from the OPENSSL_IMPLEMENT_GLOBAL definition in
e_os2.h and include/openssl/e_os2.h.
[end quote]
So I tried that but it didn't work. There must be a crucial instruction
that's not mentioned there.
> Why do not just switch to 1.+ version ?
I'm running the 1.0.0 test suite as I write.
Main problem with 1.0.0 was that engines/e_capi.c uses symbols that the
wincrypt.h header from mingw.org doesn't define.
However, I found these symbols in the mingw64.sf version of wincrypt.h and
modified e_capi.c to include the needed definitions.
The tests have just concluded with:
########################
CMS consistency test
perl cms-test.pl
'..' is not recognized as an internal or external command,
operable program or batch file.
CMS => PKCS#7 compatibility tests
signed content DER format, RSA key: generation error
make[1]: *** [test_cms] Error 1
make[1]: Leaving directory `/c/_32/comp/openssl-1.0.0/test'
make: *** [tests] Error 2
########################
I think it's just that I'm still using ActivePerl instead of msys perl.
(I'll check on that by rebuilding using msys perl - I have to rebuild anyway
as I forgot to specify the --prefix for installation.)
Thanks Roumen.
Sisyphus
----- Original Message -----
From: "Sisyphus"
> Interestingly, there's no problem building a static openssl (so long as
> one
> uses a native Win32 perl
I was sent (offlist) a link to:
http://wagner.pp.ru/~vitus/articles/openssl-mingw.html
In the section "Doing Shared Build", I couldn't quite follow the proposed
fix, though it seemed the author had identified the problem.
Based on that article, before I ran 'make' I opened the top level Makefile
and changed:
SHARED_LDFLAGS=-mno-cygwin -shared
to
SHARED_LDFLAGS=-mno-cygwin -Wl,--export-all -shared
The dynamic build of 0.9.8o then built and tested fine.
(This post is mainly "just for the record". Now that I've discovered that I
*can* build 1.0.0, I'll probably stick with it.)
Thanks guys.
Keith Marshall
> Based on that article, before I ran 'make' I opened the top level
> Makefile and changed:
>
> SHARED_LDFLAGS=-mno-cygwin -shared
> to
> SHARED_LDFLAGS=-mno-cygwin -Wl,--export-all -shared
FTR, -mno-cygwin is completely irrelevant for a native MinGW build; it
is a (IMO nasty) cygwin kludge to induce cross-compiling, (which is now
deprecated in favour of a proper cross-compiler set-up, AFAIK), from a
cygwin build environment.
--
Regards,
Keith.