Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[libtasn1] Add Windows support, update to 4.17 #16953

Merged
merged 11 commits into from
May 25, 2021

Conversation

wrobelda
Copy link
Contributor

@wrobelda wrobelda commented Mar 29, 2021

Describe the pull request
Enables windows build

  • Which triplets are supported/not supported? Have you updated the CI baseline?

static-md build is unsupported. CI baseline updated.

Yes.

@wrobelda wrobelda changed the title [libtasn1] Add Windows support [libtasn1] Add Windows support (WIP) Mar 29, 2021
@wrobelda
Copy link
Contributor Author

wrobelda commented Mar 29, 2021

Currently stuck at:

asn1Coding.obj : error LNK2019: unresolved external symbol __imp__asn1_parser2tree referenced in function _main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp__asn1_print_structure referenced in function _main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp__asn1_create_element referenced in function _main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp__asn1_delete_structure referenced in function _main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp__asn1_write_value referenced in function _main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp__asn1_der_coding referenced in function _main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp__asn1_strerror referenced in function _main
.libs\asn1Coding.exe : fatal error LNK1120: 7 unresolved externals
asn1Parser.obj : error LNK2019: unresolved external symbol __imp__asn1_parser2tree referenced in function _main
asn1Parser.obj : error LNK2019: unresolved external symbol __imp__asn1_parser2array referenced in function _main
asn1Parser.obj : error LNK2019: unresolved external symbol __imp__asn1_delete_structure referenced in function _main
asn1Parser.obj : error LNK2019: unresolved external symbol __imp__asn1_strerror referenced in function _main
.libs\asn1Parser.exe : fatal error LNK1120: 4 unresolved externals
cl : Command line warning D9002 : ignoring unknown option '-fno-common'
cl : Command line warning D9002 : ignoring unknown option '-fno-common'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-show-option'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-color=always'
cl : Command line warning D9002 : ignoring unknown option '-fno-common'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-show-option'
cl : Command line warning D9002 : ignoring unknown option '-fno-common'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-show-option'
cl : Command line warning D9002 : ignoring unknown option '-fno-common'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-color=always'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-show-option'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-color=always'
cl : Command line warning D9002 : ignoring unknown option '-fno-common'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-show-option'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-color=always'
cl : Command line warning D9002 : ignoring unknown option '-fno-common'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-show-option'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-color=always'
cl : Command line warning D9002 : ignoring unknown option '-fno-common'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-show-option'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-color=always'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-show-option'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-color=always'
cl : Command line warning D9002 : ignoring unknown option '-fdiagnostics-color=always'
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp__asn1_parser2tree referenced in function _main
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp__asn1_print_structure referenced in function _simple_decode
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp__asn1_create_element referenced in function _simple_decode
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp__asn1_delete_structure referenced in function _main
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp__asn1_der_decoding2 referenced in function _simple_decode
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp__asn1_der_decoding referenced in function _simple_decode
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp__asn1_strerror referenced in function _main
.libs\asn1Decoding.exe : fatal error LNK1120: 7 unresolved externals
make[2]: Leaving directory '/cygdrive/c/vcpkg/buildtrees/libtasn1/x86-windows-dbg/src'
make[1]: Leaving directory '/cygdrive/c/vcpkg/buildtrees/libtasn1/x86-windows-dbg'

Something's off with linker, it fails to resolve own symbols, as well as generated executables (e.g. asn1Coding.exe), which seems odd, although I am not very familiar with MSVC.

@wrobelda
Copy link
Contributor Author

wrobelda commented Mar 30, 2021

OK, so what I see is:

/bin/sh ../libtool  --tag=CC   --mode=link compile cl.exe -fno-common -Wall -fdiagnostics-show-option -fdiagnostics-color=always   -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -Xcompiler -RTC1  -LC:/vcpkg/installed/x86-windows/debug/lib/manual-link/ -lgettimeofday -lgetopt -o asn1Decoding.exe asn1Decoding.obj benchmark.obj ../lib/libtasn1.la -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -lcomdlg32 -ladvapi32

followed by:

libtool: link: compile cl.exe -fno-common -Wall -fdiagnostics-show-option -fdiagnostics-color=always -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -RTC1 -o .libs/asn1Coding.exe asn1Coding.obj  -LC:/vcpkg/installed/x86-windows/debug/lib/manual-link/ ../lib/.libs/tasn1.lib -lgettimeofday -lgetopt -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -lcomdlg32 -ladvapi32

The missing symbols are in ../lib/libtasn1.la, which is what libtool asks for, yet the the actual command issued has an incorrect ../lib/.libs/tasn1.lib, so something is messing the path up in the process.

@wrobelda
Copy link
Contributor Author

wrobelda commented Mar 30, 2021

Most interestingly, the problematic ../lib/.libs/tasn1.lib ends up in the middle of my additional, explicit LDFLAGS:
-LC:/vcpkg/installed/x86-windows/debug/lib/manual-link/ ../lib/.libs/tasn1.lib -lgettimeofday. I suspect some regex issue, investigating further.

@NancyLi1013 NancyLi1013 self-assigned this Mar 30, 2021
@wrobelda
Copy link
Contributor Author

wrobelda commented Mar 30, 2021

I tried setting the LDFLAGS using env variable instead (set(ENV{LDFLAGS} "$ENV{LDFLAGS} -L${CURRENT_INSTALLED_DIR}/lib/manual-link -lgettimeofday -lgetopt"), but it is being ignored.

EDIT: Gonna try with vcpkg_configure_make's CONFIGURE_ENVIRONMENT_VARIABLES option instead.

@wrobelda
Copy link
Contributor Author

wrobelda commented Mar 30, 2021

OK, so I tried setting the LDFLAGS using CONFIGURE_ENVIRONMENT_VARIABLES to see if it makes any difference, but it doesn't: the ../lib/libtasn1.la somehow still ends up as ../lib/.libs/tasn1.lib , in the middle of my LDFLAGS:

/bin/sh ../libtool  --tag=CC   --mode=link compile cl.exe -fno-common -Wall -fdiagnostics-show-option -fdiagnostics-color=always   -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -Xcompiler -RTC1  -LC:/vcpkg/installed/x86-windows/lib/manual-link -lgettimeofday -lgetopt -o asn1Decoding.exe asn1Decoding.obj benchmark.obj ../lib/libtasn1.la -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -lcomdlg32 -ladvapi32
libtool: link: compile cl.exe -fno-common -Wall -fdiagnostics-show-option -fdiagnostics-color=always -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -RTC1 -o .libs/asn1Parser.exe asn1Parser.obj  -LC:/vcpkg/installed/x86-windows/lib/manual-link ../lib/.libs/tasn1.lib -lgettimeofday -lgetopt -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -lcomdlg32 -ladvapi32
libtool: link: compile cl.exe -fno-common -Wall -fdiagnostics-show-option -fdiagnostics-color=always -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -RTC1 -o .libs/asn1Coding.exe asn1Coding.obj  -LC:/vcpkg/installed/x86-windows/lib/manual-link ../lib/.libs/tasn1.lib -lgettimeofday -lgetopt -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -lcomdlg32 -ladvapi32

This is clearly some bug.

@NancyLi1013 NancyLi1013 added the category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist label Mar 30, 2021
@Neumann-A
Copy link
Contributor

That is probably a bug in a Makefile of the project.

@wrobelda
Copy link
Contributor Author

wrobelda commented Mar 30, 2021

That is probably a bug in a Makefile of the project.

Well, actually, I read too much into the command line, while forgetting to check the obvious: the ../lib/.libs/tasn1.lib actually exists and is a proper binary library file. I checked the symbols in it (using dumpbin /SYMBOLS) and it does have the symbols the linker complains about:

020 00000000 UNDEF  notype ()    External     | _asn1_create_element
021 00000000 UNDEF  notype ()    External     | _asn1_delete_structure
022 00000000 UNDEF  notype ()    External     | _asn1_read_value
023 00000000 SECT3  notype ()    External     | _asn1_der_decoding2
024 00001700 SECT3  notype ()    External     | _asn1_der_decoding
025 00001730 SECT3  notype ()    External     | _asn1_der_decoding_element
026 00001760 SECT3  notype ()    External     | _asn1_der_decoding_startEnd
027 000018A0 SECT3  notype ()    External     | _asn1_expand_any_defined_by
028 00001F60 SECT3  notype ()    External     | _asn1_expand_octet_string
029 00002440 SECT3  notype ()    External     | _asn1_get_length_der
02A 000026E0 SECT3  notype ()    External     | _asn1_get_length_ber
02B 00002780 SECT3  notype ()    External     | _asn1_decode_simple_der
02C 000027B0 SECT3  notype ()    External     | _asn1_decode_simple_ber
02D 00000000 UNDEF  notype ()    External     | _asn1_find_node
02E 000027E0 SECT3  notype ()    External     | _asn1_get_tag_der
02F 00002B70 SECT3  notype ()    External     | _asn1_get_octet_der
030 00002C50 SECT3  notype ()    External     | _asn1_get_bit_der
031 00002D50 SECT3  notype ()    External     | _asn1_get_object_id_der
032 000031C0 SECT3  notype ()    Static       | _type_field
033 000031D0 SECT3  notype ()    Static       | __asn1_realloc
034 00000000 UNDEF  notype ()    External     | __asn1_set_value
035 00000000 UNDEF  notype ()    External     | __asn1_set_value_lv
036 00000000 UNDEF  notype ()    External     | __asn1_cpy_name
037 00000000 UNDEF  notype ()    External     | __asn1_set_right
038 00000000 UNDEF  notype ()    External     | __asn1_ltostr
039 00000000 UNDEF  notype ()    External     | __asn1_find_up
03A 00000000 UNDEF  notype ()    External     | __asn1_str_cpy
03B 00000000 UNDEF  notype ()    External     | __asn1_str_cat
03C 00000000 UNDEF  notype ()    External     | __asn1_find_left
03D 00000000 UNDEF  notype ()    External     | __asn1_append_sequence_set
03E 00000000 UNDEF  notype ()    External     | __asn1_hierarchical_name

However, the dumpbin /EXPORTS returns a summary only, with no symbols, so clearly they were not exported. At this point the lates lead is the the libtasn1.h and __declspec(dllexport)/__declspec(dllimport) decorators definitions:

#ifndef ASN1_API
#if defined ASN1_BUILDING && defined HAVE_VISIBILITY && HAVE_VISIBILITY
#define ASN1_API __attribute__((__visibility__("default")))
#elif defined ASN1_BUILDING && defined _MSC_VER && ! defined ASN1_STATIC
#define ASN1_API __declspec(dllexport)
#elif defined _MSC_VER && ! defined ASN1_STATIC
#define ASN1_API __declspec(dllimport)
#else
#define ASN1_API
#endif
#endif

Checking further.

EDIT: also checking libtool's -export-symbols-regex '^(asn1|libtasn1_).*', which seems that it would filter out the _asn symbols.

@wrobelda
Copy link
Contributor Author

wrobelda commented Mar 30, 2021

OK, so this is till to do with overloading LDFLAGS. From the build log:

*** Warning: linker path does not have real file for library -lgetopt.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with getopt but no candidates were found. (...for file magic test)
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

It fails to find getopt, which is in fact installed properly, clearly indicating the default vcpkg's LDFLAGS are lost when overriding LDFLAGS – even when back referencing the previously set ones.

Setting LDFLAGS with set(LDFLAGS "${LDFLAGS} -lgetopt -L${CURRENT_INSTALLED_DIR}/lib/manual-link -lgettimeofday") ends up with following lines in config.log:

LDFLAGS=' -lgetopt -LC:/vcpkg/installed/x86-windows/lib/manual-link -lgettimeofday'

Not setting it will get:

LDFLAGS='-LC:/vcpkg/installed/x86-windows/debug/lib -LC:/vcpkg/installed/x86-windows/debug/lib/manual-link'

So:
a) LDFLAGS already comes with manual-link preconfigured (this could be documented somewhere)
b) appending to LDFLAGS seems impossible, as back-referencing ${LDFLAGS} or ${VCPKG_LINKER_FLAGS} doesn't work

@wrobelda
Copy link
Contributor Author

wrobelda commented Mar 30, 2021

Given how vcpkg already configured LDFLAGS as required, I only needed to set the LIBS.

This was also problematic, given how setting the environment variable would override vcpkg's own list of libraries (LIBS='-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -lcomdlg32 -ladvapi32').

I worked around by passing LIBS as a regular option to vcpkg_configure_make and have it use shell to expand the environment LIB variable at the time of execution: set(LIBS "$LIBS -lgettimeofday -lgetopt")

@wrobelda wrobelda force-pushed the libtasn1_windows branch 6 times, most recently from 2cc70e3 to 713059e Compare March 31, 2021 02:48
@wrobelda
Copy link
Contributor Author

wrobelda commented Mar 31, 2021

Build still fails on CI/CD, but I cannot reproduce those errors locally on my Windows dev box:

libtool: compile:  /cygdrive/d/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe -DHAVE_CONFIG_H -I. -I../.././../src/4.16.0-e9554bb491.clean/lib/gl -I../.. -DWIN32 -D_WINDOWS -D_DEBUG -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -RTC1 -Od -c -showIncludes ../.././../src/4.16.0-e9554bb491.clean/lib/gl/strverscmp.c -o strverscmp.obj
strverscmp.c
D:\buildtrees\libtasn1\x86-windows-dbg\lib\gl\stdint.h(77): fatal error C1083: Cannot open include file: '': No such file or directory

Line 77 of lib\gl\stdint.h is: # include_next <stdint.h>

Everything compiles fine for me locally. Could be it a different MSVC version?

@wrobelda wrobelda marked this pull request as ready for review April 1, 2021 23:27
@NancyLi1013
Copy link
Contributor

The latest failures on Windows:

From build-x64-windows-dbg-err.log

ar-lib: unknown action specified
make[5]: *** [Makefile:687: libgnu.la] Error 1
make[4]: *** [Makefile:738: all-recursive] Error 1
make[3]: *** [Makefile:638: all] Error 2
make[2]: *** [Makefile:808: all-recursive] Error 1
make[1]: *** [Makefile:655: all-recursive] Error 1
make: *** [Makefile:584: all] Error 2

Could you please look into this? @wrobelda

@wrobelda
Copy link
Contributor Author

wrobelda commented May 19, 2021

EDIT: the below is fixed now

OK, I am stuck, tbh.

The build fails differently for x86 and x64 platforms. On x86 I am seeing:

make[5]: Entering directory '/c/vcpkg/buildtrees/libtasn1/x86-windows-dbg/lib/gl'
Makefile:721: update target 'c-ctype.lo' due to: ../.././../src/4.16.0-e9554bb491.clean/lib/gl/c-ctype.c
source='../.././../src/4.16.0-e9554bb491.clean/lib/gl/c-ctype.c' object='c-ctype.lo' libtool=yes \
DEPDIR=.deps depmode=msvc7 /bin/sh ../.././../src/4.16.0-e9554bb491.clean/build-aux/depcomp \
/bin/sh ../../libtool  --tag=CC   --mode=compile /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe -DHAVE_CONFIG_H -I. -I../.././../src/4.16.0-e9554bb491.clean/lib/gl -I../..   -DWIN32 -D_WINDOWS -D_DEBUG  -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -Xcompiler -RTC1 -c -o c-ctype.lo ../.././../src/4.16.0-e9554bb491.clean/lib/gl/c-ctype.c
Makefile:721: update target 'strverscmp.lo' due to: ../.././../src/4.16.0-e9554bb491.clean/lib/gl/strverscmp.c
source='../.././../src/4.16.0-e9554bb491.clean/lib/gl/strverscmp.c' object='strverscmp.lo' libtool=yes \
DEPDIR=.deps depmode=msvc7 /bin/sh ../.././../src/4.16.0-e9554bb491.clean/build-aux/depcomp \
/bin/sh ../../libtool  --tag=CC   --mode=compile /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe -DHAVE_CONFIG_H -I. -I../.././../src/4.16.0-e9554bb491.clean/lib/gl -I../..   -DWIN32 -D_WINDOWS -D_DEBUG  -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -Xcompiler -RTC1 -c -o strverscmp.lo ../.././../src/4.16.0-e9554bb491.clean/lib/gl/strverscmp.c
libtool: compile:  /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe -DHAVE_CONFIG_H -I. -I../.././../src/4.16.0-e9554bb491.clean/lib/gl -I../.. -DWIN32 -D_WINDOWS -D_DEBUG -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -RTC1 -Od -c -showIncludes ../.././../src/4.16.0-e9554bb491.clean/lib/gl/c-ctype.c  -DDLL_EXPORT -DPIC -o .libs/c-ctype.obj
c-ctype.c
libtool: compile:  /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe -DHAVE_CONFIG_H -I. -I../.././../src/4.16.0-e9554bb491.clean/lib/gl -I../.. -DWIN32 -D_WINDOWS -D_DEBUG -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -RTC1 -Od -c -showIncludes ../.././../src/4.16.0-e9554bb491.clean/lib/gl/strverscmp.c  -DDLL_EXPORT -DPIC -o .libs/strverscmp.obj
strverscmp.c
Makefile:687: update target 'libgnu.la' due to: c-ctype.lo strverscmp.lo
/bin/sh ../../libtool  --tag=CC   --mode=link /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe  -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -Xcompiler -RTC1  -no-undefined -LC:/vcpkg/installed/x86-windows/debug/lib -LC:/vcpkg/installed/x86-windows/debug/lib/manual-link -o libgnu.la  c-ctype.lo strverscmp.lo -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -lcomdlg32 -ladvapi32 -lgettimeofday -lgetopt
libtool: link: lib.exe cru .libs/gnu.lib .libs/c-ctype.obj .libs/strverscmp.obj 
Microsoft (R) Library Manager Version 14.28.29337.0
Copyright (C) Microsoft Corporation.  All rights reserved.

LINK : fatal error LNK1181: cannot open input file 'cru'
make[5]: Leaving directory '/c/vcpkg/buildtrees/libtasn1/x86-windows-dbg/lib/gl'

And on x64:

make[5]: Entering directory '/c/vcpkg/buildtrees/libtasn1/x64-windows-dbg/lib/gl'
Makefile:721: update target 'c-ctype.lo' due to: ../.././../src/4.16.0-e9554bb491.clean/lib/gl/c-ctype.c
source='../.././../src/4.16.0-e9554bb491.clean/lib/gl/c-ctype.c' object='c-ctype.lo' libtool=yes \
DEPDIR=.deps depmode=msvc7 /bin/sh ../.././../src/4.16.0-e9554bb491.clean/build-aux/depcomp \
/bin/sh ../../libtool  --tag=CC   --mode=compile /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe -DHAVE_CONFIG_H -I. -I../.././../src/4.16.0-e9554bb491.clean/lib/gl -I../..   -DWIN32 -D_WINDOWS -D_DEBUG  -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -Xcompiler -RTC1 -c -o c-ctype.lo ../.././../src/4.16.0-e9554bb491.clean/lib/gl/c-ctype.c
Makefile:721: update target 'strverscmp.lo' due to: ../.././../src/4.16.0-e9554bb491.clean/lib/gl/strverscmp.c
source='../.././../src/4.16.0-e9554bb491.clean/lib/gl/strverscmp.c' object='strverscmp.lo' libtool=yes \
DEPDIR=.deps depmode=msvc7 /bin/sh ../.././../src/4.16.0-e9554bb491.clean/build-aux/depcomp \
/bin/sh ../../libtool  --tag=CC   --mode=compile /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe -DHAVE_CONFIG_H -I. -I../.././../src/4.16.0-e9554bb491.clean/lib/gl -I../..   -DWIN32 -D_WINDOWS -D_DEBUG  -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -Xcompiler -RTC1 -c -o strverscmp.lo ../.././../src/4.16.0-e9554bb491.clean/lib/gl/strverscmp.c
libtool: compile:  /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe -DHAVE_CONFIG_H -I. -I../.././../src/4.16.0-e9554bb491.clean/lib/gl -I../.. -DWIN32 -D_WINDOWS -D_DEBUG -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -RTC1 -Od -c -showIncludes ../.././../src/4.16.0-e9554bb491.clean/lib/gl/strverscmp.c -o strverscmp.obj
strverscmp.c
libtool: compile:  /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe -DHAVE_CONFIG_H -I. -I../.././../src/4.16.0-e9554bb491.clean/lib/gl -I../.. -DWIN32 -D_WINDOWS -D_DEBUG -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -RTC1 -Od -c -showIncludes ../.././../src/4.16.0-e9554bb491.clean/lib/gl/c-ctype.c -o c-ctype.obj
c-ctype.c
Makefile:687: update target 'libgnu.la' due to: c-ctype.lo strverscmp.lo
/bin/sh ../../libtool  --tag=CC   --mode=link /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/compile cl.exe  -nologo -W3 -utf-8 -MP -MDd -Z7 -Ob0 -Od -Xcompiler -RTC1  -no-undefined -LC:/vcpkg/installed/x64-windows/debug/lib -LC:/vcpkg/installed/x64-windows/debug/lib/manual-link -o libgnu.la  c-ctype.lo strverscmp.lo -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -lcomdlg32 -ladvapi32 -lgettimeofday -lgetopt
libtool: link: /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/ar-lib /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/ar-lib lib.exe cru .libs/libgnu.a  c-ctype.obj strverscmp.obj
make[5]: Leaving directory '/c/vcpkg/buildtrees/libtasn1/x64-windows-dbg/lib/gl'

With the stderr being:
ar-lib: unknown action specified

The x64 libtool call seems to reference ar-lib twice – could that explain the unknown action specified?
libtool: link: /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/ar-lib /c/vcpkg/buildtrees/libtasn1/src/4.16.0-e9554bb491.clean/build-aux/ar-lib lib.exe cru .libs/libgnu.a c-ctype.obj strverscmp.obj

@wrobelda wrobelda changed the title [libtasn1] Add Windows support (WIP) [libtasn1] Add Windows support, update to 4.17 (WIP) May 19, 2021
@wrobelda
Copy link
Contributor Author

@NancyLi1013 all issues are fixed now.

@NancyLi1013 NancyLi1013 added the category:port-update The issue is with a library, which is requesting update new revision label May 20, 2021
@NancyLi1013 NancyLi1013 added info:reviewed Pull Request changes follow basic guidelines and removed requires:author-response labels May 20, 2021
@NancyLi1013
Copy link
Contributor

LGTM now. thanks for your work @wrobelda.

@strega-nil-ms
Copy link
Contributor

LGTM! Thanks @wrobelda :)

@strega-nil-ms strega-nil-ms merged commit 83f9a6c into microsoft:master May 25, 2021
@Neumann-A
Copy link
Contributor

CI baseline regression in static builds:

   Creating library asn1Parser.lib and object asn1Parser.exp
asn1Parser.obj : error LNK2019: unresolved external symbol __imp_asn1_parser2tree referenced in function main
asn1Parser.obj : error LNK2019: unresolved external symbol __imp_asn1_parser2array referenced in function main
asn1Parser.obj : error LNK2019: unresolved external symbol __imp_asn1_delete_structure referenced in function main
asn1Parser.obj : error LNK2019: unresolved external symbol __imp_asn1_strerror referenced in function main
asn1Parser.exe : fatal error LNK1120: 4 unresolved externals
   Creating library asn1Decoding.lib and object asn1Decoding.exp
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp_asn1_parser2tree referenced in function main
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp_asn1_print_structure referenced in function simple_decode
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp_asn1_create_element referenced in function simple_decode
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp_asn1_delete_structure referenced in function main
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp_asn1_der_decoding2 referenced in function simple_decode
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp_asn1_der_decoding referenced in function simple_decode
asn1Decoding.obj : error LNK2019: unresolved external symbol __imp_asn1_strerror referenced in function main
asn1Decoding.exe : fatal error LNK1120: 7 unresolved externals

@wrobelda
Copy link
Contributor Author

wrobelda commented May 25, 2021

CI baseline regression in static builds:

Just realized that the most recent CI/CD build was libtasn1:x64-windows-static: cascade:. I'll look into it. I guess it can be added to ci.baseline.txt as failing for the time being.

strega-nil added a commit to strega-nil/vcpkg that referenced this pull request May 25, 2021
@wrobelda
Copy link
Contributor Author

wrobelda commented May 25, 2021

CI baseline regression in static builds:

@Neumann-A OK, I thought it was about the x64-windows-static, which refuses to build due to getopt issue, which in turn explains the cascade in CI/CD .

Your log section corresponds to x64-windows-static-md, which I had already added to scripts/ci.baseline.txt as failing. I did not have any more time to work on it, and with x64-windows-static-md being an unofficial triplet, I figured it was worth pushing the changes as is.

@JackBoosY
Copy link
Contributor

JackBoosY commented May 26, 2021

asn1Coding.obj : error LNK2019: unresolved external symbol __imp_asn1_parser2tree referenced in function main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp_asn1_print_structure referenced in function main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp_asn1_create_element referenced in function main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp_asn1_delete_structure referenced in function main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp_asn1_write_value referenced in function main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp_asn1_der_coding referenced in function main
asn1Coding.obj : error LNK2019: unresolved external symbol __imp_asn1_strerror referenced in function main

Please notice the prefix __imp_, it must use the dynamic declearation of the functions in static build.

Edit:
in libtasn1.h:

extern ASN1_API int
  asn1_parser2tree (const char *file,
		      asn1_node * definitions, char *error_desc);
#ifndef ASN1_API
#if defined ASN1_BUILDING && defined HAVE_VISIBILITY && HAVE_VISIBILITY
#define ASN1_API __attribute__((__visibility__("default")))
#elif defined ASN1_BUILDING && defined _MSC_VER && ! defined ASN1_STATIC
#define ASN1_API __declspec(dllexport)
#elif defined _MSC_VER && ! defined ASN1_STATIC
#define ASN1_API __declspec(dllimport)
#else
#define ASN1_API
#endif
#endif

I can confirm ASN1_STATIC was not added to the compile command, that caused this issue.
Will fix it now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist category:port-update The issue is with a library, which is requesting update new revision info:reviewed Pull Request changes follow basic guidelines
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants