Does not pass on HPE NonStop

[rsbeckerca]

I am building using c99 on HPE NonStop ia64 and x86. Test suite is failing as follows. Let me know what more information I can supply for diagnosis. Also, the -shared option is wrong on this platform. We need -Wshared and some LDFLAGS for export options.

=======================================
   jansson 2.14: test/test-suite.log
=======================================

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: run-suites
================

Suite: api
F..................
=================================================================
api/check-exports
=================================================================
--- logs/api/check-exports/exports      2022-03-19 18:10:13 -0500
+++ logs/api/check-exports/output       2022-03-19 18:10:13 -0500
@@ -1,81 +0,0 @@
-jansson_version_cmp
-jansson_version_str
-json_array
-json_array_append_new
-json_array_clear
-json_array_extend
-json_array_get
-json_array_insert_new
-json_array_remove
-json_array_set_new
-json_array_size
-json_copy
-json_deep_copy
-json_delete
-json_dump_callback
-json_dump_file
-json_dumpb
-json_dumpf
-json_dumpfd
-json_dumps
-json_equal
-json_false
-json_get_alloc_funcs
-json_integer
-json_integer_set
-json_integer_value
-json_load_callback
-json_load_file
-json_loadb
-json_loadf
-json_loadfd
-json_loads
-json_null
-json_number_value
-json_object
-json_object_clear
-json_object_del
-json_object_deln
-json_object_get
-json_object_getn
-json_object_iter
-json_object_iter_at
-json_object_iter_key
-json_object_iter_key_len
-json_object_iter_next
-json_object_iter_set_new
-json_object_iter_value
-json_object_key_to_iter
-json_object_seed
-json_object_set_new
-json_object_set_new_nocheck
-json_object_setn_new
-json_object_setn_new_nocheck
-json_object_size
-json_object_update
-json_object_update_existing
-json_object_update_missing
-json_object_update_recursive
-json_pack
-json_pack_ex
-json_real
-json_real_set
-json_real_value
-json_set_alloc_funcs
-json_sprintf
-json_string
-json_string_length
-json_string_nocheck
-json_string_set
-json_string_set_nocheck
-json_string_setn
-json_string_setn_nocheck
-json_string_value
-json_stringn
-json_stringn_nocheck
-json_true
-json_unpack
-json_unpack_ex
-json_vpack_ex
-json_vsprintf
-json_vunpack_ex

=================================================================
Suite: encoding-flags
............
Suite: invalid
..................................................
Suite: invalid-unicode
..................
Suite: valid
..................................
1 of 5 test suites failed
FAIL run-suites (exit status: 1)

[michael-o]

Intersting, Jansson just works for me on HP-UX IA64 with aCC.

[rsbeckerca]

Intersting, Jansson just works for me on HP-UX IA64 with aCC.

Definitely different compiler. What can I check to examine this or what information can I provide and how?

[michael-o]

One of the first questions is: Is your system supported by GNU autoconf to properly detect the compiler and OS to set right flags?

[rsbeckerca]

One of the first questions is: Is your system supported by GNU autoconf to properly detect the compiler and OS to set right flags?

Autoconf gets the compiler and OS correct, but the flags are not always correct. In any event, the platforms are BigEndian even though one is x86 - done in millicode. A sample build line is:

/bin/sh ../libtool  --tag=CC   --mode=compile c99 -DHAVE_CONFIG_H -I. -I..   -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1  -g -c -o utf.lo utf.c
 c99 -DHAVE_CONFIG_H -I. -I.. -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -g -c utf.c -o utf.o
          buffer[0] = 0xC0 + ((codepoint & 0x7C0) >> 6);
                      ^
"/home/randall/jansson/src/utf.c", line 18: warning(1506): implicit conversion
          from "int" to "char":  rounding, sign extension, or loss of accuracy
          may result

I am somewhat concerned about the particular type of warning above that looks potentially endian-specific.

[michael-o]

I had these with other software which did not properly detect that HP-UX is BE. I fixed many, e.g., git and sha1collision. I guess you need to take care of that yourself.

[rsbeckerca]

I had these with other software which did not properly detect that HP-UX is BE. I fixed many, e.g., git and sha1collision. I guess you need to take care of that yourself.

How does the code, in general, know to do BE vs. LE? Is there an extra verbose mode for testing that will show where the failures actually are so I can plug away at it?

[rsbeckerca]

The API failure is a result of the DLL export not working. configure assumes gcc compatible flags.

[rsbeckerca]

@michael-o Do you know how to inject -Weld=-export_all into the LDFLAGS for shared libraries. I'm specifying CC=c99 on the configure environment, so need to tell this configure script how to do that and accept the alternate flags.

[michael-o]

Standard GNU autoconf: CFLAGS, LDFLAGS and CPPFLAGS, CC, CXX env vars. But if the Makefile does not obey them you are busted.

[rsbeckerca]

Standard GNU autoconf: CFLAGS, LDFLAGS and CPPFLAGS, CC, CXX env vars. But if the Makefile does not obey them you are busted.

This is more for the specific link of the .so file, not the individual compiles. None of those flags apply. I need to convince configure that the platform supports shared libraries but it seems to assume the -PIC and -share flags.

[michael-o]

Standard GNU autoconf: CFLAGS, LDFLAGS and CPPFLAGS, CC, CXX env vars. But if the Makefile does not obey them you are busted.

This is more for the specific link of the .so file, not the individual compiles. None of those flags apply. I need to convince configure that the platform supports shared libraries but it seems to assume the -PIC and -share flags.

This still confuses me. Let me double check tomorrow what autoconf does on HP-UX.

[akheron]

This test only checks that correct symbols are exported in the shared object. Output of nm is probably just different on your system than what the test expects.