From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 6B194395BC77 for ; Tue, 8 Jun 2021 15:45:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6B194395BC77 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 158FXXNI168335 for ; Tue, 8 Jun 2021 11:45:57 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 392b2a129t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 08 Jun 2021 11:45:57 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 158FhF3N016201 for ; Tue, 8 Jun 2021 15:45:56 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma01dal.us.ibm.com with ESMTP id 3900w9eftn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 08 Jun 2021 15:45:56 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 158Fjt7p7733612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 8 Jun 2021 15:45:55 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1D20B13607D for ; Tue, 8 Jun 2021 15:45:55 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DF121136063 for ; Tue, 8 Jun 2021 15:45:54 +0000 (GMT) Received: from mww0171.wdc07m.mail.ibm.com (unknown [9.208.70.164]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP for ; Tue, 8 Jun 2021 15:45:54 +0000 (GMT) Subject: Compliation issues with x86/libffi To: libffi-discuss@sourceware.org Message-ID: From: "Cheng Jin" Date: Tue, 8 Jun 2021 11:45:51 -0400 X-KeepSent: DAB297F2:95260E91-002586EE:00543DE7; name=$KeepSent; type=4 X-Mailer: IBM Notes Release 10.0.1 November 29, 2018 X-Disclaimed: 46491 X-MIMETrack: CD-MIME by Router on MWW0171/01/M/IBM at 06/08/2021 15:45:54, CD-MIME complete at 06/08/2021 15:45:54,Itemize by Router on MWW0171/01/M/IBM at 06/08/2021 15:45:54 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: tgzzj8t0tqsuxoOVQKc_cTGFuCTIRoxM X-Proofpoint-GUID: tgzzj8t0tqsuxoOVQKc_cTGFuCTIRoxM X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-06-08_10:2021-06-04, 2021-06-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 mlxlogscore=988 clxscore=1011 lowpriorityscore=0 mlxscore=0 spamscore=0 phishscore=0 bulkscore=0 adultscore=0 suspectscore=0 impostorscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106080099 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 15:46:00 -0000 Hi, We are currently exploiting the latest version x86/libffi at https://github.com/libffi/libffi/tree/master/src/x86 in our project but there were a few compilation issues we detected on various platforms. [1] Linux/64bit (compilation was based on the guideline at https://github.com/libffi/libffi/blob/master/configure.host) X86_64) if test x"$TARGET_X32" =3D xyes; then SOURCES=3D"ffi64.c unix64.S" else SOURCES=3D"ffi64.c unix64.S ffiw64.c win64.S" <--------- fi The compilation passed on Ubuntu 19 with GCC 9 plus the GLIBC 2.31 but it failed on Redhat6 with GCC 7.5 plus GLIBC 2.12 as follows: gcc -O3 -fno-strict-aliasing -fgnu89-inline -g ...-fPIC -m64 -fstack-protector -I. ... -Wno-unused-result -c -o closures.o closures.c gcc -O3 -fno-strict-aliasing -fgnu89-inline -g ...-fPIC -m64 -fstack-protector -I. ... -c -o debug.o debug.c gcc -O3 -fno-strict-aliasing -fgnu89-inline -g ...-fPIC -fstack-protector -I. ...-c -o ffi64.o x86/ffi64.c gcc -O3 -fno-strict-aliasing -fgnu89-inline -g ...-fPIC -m64 -fstack-protector -I. ...-c -o ffiw64.o x86/ffiw64.c gcc -O3 -fno-strict-aliasing -fgnu89-inline -g ...-fPIC -m64 -fstack-protector -I. ...-c -o java_raw_api.o java_raw_api.c gcc -O3 -fno-strict-aliasing -fgnu89-inline -g ...-fPIC -m64 -fstack-protector -I. ...-c -o prep_cif.o prep_cif.c gcc -O3 -fno-strict-aliasing -fgnu89-inline -g ...-fPIC -m64 -fstack-protector -I. ...-c -o raw_api.o raw_api.c gcc -O3 -fno-strict-aliasing -fgnu89-inline -g ... -fPIC -m64 -fstack-protector -I. ...-c -o types.o types.c gcc -Xassembler -noexecstack -Xassembler -64 -Xassembler --gdwarf2 -Xassembler -I. -Xassembler -I../include ... -c -o unix64.o x86/unix64.S gcc -Xassembler -noexecstack -Xassembler -64 -Xassembler --gdwarf2 -Xassembler -I. -Xassembler -I../include ... -c -o win64.o x86/win64.S ar rcv ../lib/libffi.a closures.o debug.o ffi64.o ffiw64.o java_raw_api.o prep_cif.o raw_api.o types.o unix64.o win64.o a - closures.o a - debug.o a - ffi64.o a - ffiw64.o a - java_raw_api.o a - prep_cif.o a - raw_api.o a - types.o a - unix64.o a - win64.o ... /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/7.5.0/../../../../x86_64-pc-l= inux-gnu/bin/ld: ../lib//libffi.a(unix64.o): relocation R_X86_64_PC32 against symbol `abort@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC <-------- /usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/7.5.0/../../../../x86_64-pc-l= inux-gnu/bin/ld: final link failed: Bad value We'd like to know why failed on the lower version of gcc and whether there is any chance to fix the issue without upgrading the gcc toolchain to the latest version (e.g. gcc 9) given there is no specific requirement on the gcc version in x86/libffi. ------------------------------------ [2] Windows/32bit (compilation with MSVC on x86_64 machines targeting for 32bit based on the guideline at https://github.com/libffi/libffi/blob/master/configure.host) X86 | X86_DARWIN | X86_FREEBSD | X86_WIN32) if test "$MSVC" =3D 1; then SOURCES=3D"ffi.c sysv_intel.S" <--------- else SOURCES=3D"ffi.c sysv.S" fi Currently our project includes an older version of x86/libffi (ffi.c & win32.S) which works fine on Windows/32bit but it failed to compile after replacing with ffi.c and sysv_intel.S ffi.lib(prep_cif.c.obj) : warning LNK4049: locally defined symbol _ffi_type_sint32 imported ffi.lib(prep_cif.c.obj) : warning LNK4049: locally defined symbol _ffi_type_float imported ffi.lib(ffi.c.obj) : error LNK2019: unresolved external symbol @ffi_call_i386@8 referenced in function _ffi_raw_call ffi.lib(sysv_intel.asm.obj) : error LNK2019: unresolved external symbol _@ffi_closure_inner@8 referenced in function _ffi_closure_i386 We tried to add the following code in sysv_intel.S (the same code as in sysv.S) /* Handle win32 fastcall name mangling. */ #ifdef X86_WIN32 # define ffi_call_i386 "@ffi_call_i386@8" # define ffi_closure_inner "@ffi_closure_inner@8" #else # define ffi_call_i386 C(ffi_call_i386) # define ffi_closure_inner C(ffi_closure_inner) #endif but still ended up with the misleading failures: ...\libffi\sysv_intel.asm(1124) specified size : error A2008:syntax error : @ffi_closure_inner@8 ...\libffi\sysv_intel.asm(1139) specified size : error A2008:syntax error : @ffi_call_i386@8 ...\libffi\sysv_intel.asm(1140) specified size : error A2008:syntax error : @ffi_call_i386@8 ...\libffi\sysv_intel.asm(1246) specified size : error A2008:syntax error : @ffi_call_i386@8 ...\libffi\sysv_intel.asm(1366) specified size So we are not too sure whether there was something we might be unaware of in terms of compilation options or something else we missed; otherwise, we might need to switch back to the older version specific to Windows/32bit to avoid such issue. Thanks and Best Regards Cheng Jin