--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-06
15:27 ---
I'm not so sure (that it's cygwin specific).
http://www.google.co.uk/search?q=locale_facets.tcc++internal++error:+Segmentation+faulthl=enclient=firefox-arls=org.mozilla:en-US:officialfilter=0
seems
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-15
19:08 ---
I've just run into this problem too.
In earlier versions of Aaron's shared libgcc patch, we extracted ctors.o and
chkstk.o and placed them whole into the import lib. I'm not sure why he didn't
do
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-15
21:18 ---
Created an attachment (id=17109)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17109action=view)
Order BACKENDLIBS by dependencies.
I'd consider this fix obvious. Verified that it resolves
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16
13:41 ---
(In reply to comment #5)
If you look at the (static) libgcc.a, when shared libs are enabled, it
contains only symbols that are not exported from the shared dll. Only the
'API-stable' symbols
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-16
13:43 ---
This bug is fixed and should be closed now. A new PR, bug 37660, has been
created for the separate issue in comment 4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-18
00:17 ---
This is now fixed.
Will file a separate PR later for -lstdc++ problems.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18
00:31 ---
Created an attachment (id=17131)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17131action=view)
Remove troublesome clause from libiberty configure
Now testing vs. both src/ and gcc/
--
http
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18
00:41 ---
Oh, I forgot to mention a further non-standardness about the DLL's name: on the
Cygwin platform, the shared library version number should be separated from the
name by a hyphen, not an underscore. So
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-01-18
05:57 ---
Created an attachment (id=17132)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132action=view)
Move _ctors* and _chkstk* to import lib
Danny, this is the approach that I think I'd like to take
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-18
21:40 ---
Fixed on HEAD by r.143487; sorry, forgot to put the PR/ reference in the SVN
logfile.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-01-19
04:54 ---
(In reply to comment #8)
(In reply to comment #7)
Created an attachment (id=17132)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132action=view) [edit]
Move _ctors* and _chkstk* to import lib
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-01-20
04:32 ---
Created an attachment (id=17151)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17151action=view)
Fill out missing syms from shared libgcc using static libgcc archive.
(In reply to comment #10
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-22
16:42 ---
Created an attachment (id=17163)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17163action=view)
Fix shared libgcc naming scheme.
Patch now in testing, fixes DLL naming scheme for both Cygwin
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-23
18:10 ---
Created an attachment (id=17168)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17168action=view)
Force assembler labels to match.
Now testing this fairly straightforward approach to making
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-23
19:02 ---
Right you are. Either one should work, but I don't have any more spare time
than you for testing things on Linux right now. It's non-critical, so I'll
keep a patch in my local tree and maybe we should
Version: 4.4.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-23
23:31 ---
Created an attachment (id=17169)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17169action=view)
Simple throw-catch testcase
Test cases don't come much simpler than this.
--
http://gcc.gnu.org
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-01-23
23:31 ---
Created an attachment (id=17170)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17170action=view)
Pre-processed source of testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-23
23:32 ---
Created an attachment (id=17171)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17171action=view)
Generated assembler for testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-23
23:44 ---
The bug manifests itself as a crash on exit from main(); $eip is set to zero
and we get a SEGV.
On entry to main(), the registers show:
esp0x22cc40 0x22cc40
ebp0x22cca8
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-01-24
00:10 ---
Here is a disassembly of the start of the main function:
(gdb) disass main
Dump of assembler code for function main:
0x00401070 main+0:push %ebp
0x00401071 main+1:mov%esp,%ebp
0x00401073
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-24
01:08 ---
Here is the RTL that is created by the .130r.eh pass: everything between note 2
and call_insn 3, was added after expand.
try_optimize_cfg iteration 2
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-01-24
06:23 ---
Not IRA-related, it seems, but reload-backend interaction. -fno-ira doesn't
make any difference to the generated code to calculate the frame pointer for
the jmp_buf. In a non-IRA build, pass 172r.lreg
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-01-24
18:12 ---
Thanks for the test results and confirmation, Uros. It looks like more or less
exactly the same list of FAILs as I see on Cygwin, so I think this confirms a
generic issue with frame pointer elimination
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-01-24
18:20 ---
[ David B. CC'd in for clarification requested ]
I'm under the impression that the bug is fixed now, so no objections from me.
I'm not sure why David B. just confirmed it though, I meant Set the bug
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-01-24
23:15 ---
(In reply to comment #16)
Just ignore my post at comment #13 to update the status. Sorry for the
noise.
I should have read to the bottom of the PR before acting.
That's ok, thanks for clearing
--- Comment #18 from dave dot korn dot cygwin at gmail dot com 2009-01-24
23:22 ---
(In reply to comment #17)
(In reply to comment #16)
Just ignore my post at comment #13 to update the status. Sorry for the
noise.
I should have read to the bottom of the PR before acting
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-01-25
05:33 ---
Thanks for your help HJ. I'll do some more debugging and add notes while
you're away. Happy New Year!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
--- Comment #12 from dave dot korn dot cygwin at gmail dot com 2009-01-25
05:56 ---
Created an attachment (id=17177)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17177action=view)
Correct code compiled with -mpreferred-stack-boundary=2
Adding -mpreferred-stack-boundary=2
--- Comment #13 from dave dot korn dot cygwin at gmail dot com 2009-01-25
05:58 ---
Created an attachment (id=17178)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17178action=view)
Diffs between good and bad versions
This shows a diff between the testcase compiled
--- Comment #14 from dave dot korn dot cygwin at gmail dot com 2009-01-25
06:05 ---
Adding -mpreferred-stack-boundary=2 to the command line generates correct
code.
Here are the diffs between code generated by that setting and the default
(-mpreferred-stack-boundary=4) for the start
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-01-25
06:33 ---
(In reply to comment #14)
And that is presumably the intention of this if clause in ix86_can_eliminate:
if (stack_realign_fp)
return ((from == ARG_POINTER_REGNUM
--- Comment #16 from dave dot korn dot cygwin at gmail dot com 2009-01-25
06:40 ---
./eh.C: In function 'int main()':
./eh.C:11: internal compiler error: in print_reg, at config/i386/i386.c:10466
Please submit a full bug report,
with preprocessed source if appropriate.
See http
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-01-25
07:47 ---
And this is what I'll try:
-- Target Hook: bool TARGET_BUILTIN_SETJMP_FRAME_VALUE ()
This target hook should return an rtx that is used to store the
address of the current frame
--- Comment #18 from dave dot korn dot cygwin at gmail dot com 2009-01-25
21:36 ---
Created an attachment (id=17183)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17183action=view)
Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE.
Now testing this patch which should fix setjmp
--- Comment #19 from dave dot korn dot cygwin at gmail dot com 2009-01-25
23:07 ---
Created an attachment (id=17184)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17184action=view)
Implement TARGET_BUILTIN_SETJMP_FRAME_VALUE *correctly*.
Dur. Corrected patch for return type
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-26
09:48 ---
http://gcc.gnu.org/ml/gcc/2009-01/msg00367.html
Confirmed by OP.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-01-26
09:58 ---
Hi HP,
(In reply to comment #5)
Glancing at the assembly and simulator trace (no looking at rtl or tree dumps
yet), the value of p (sp after the first alloca) is somehow lost and after
--- Comment #8 from dave dot korn dot cygwin at gmail dot com 2009-01-26
18:49 ---
Oh, bah, I misread the Host field for Target!
Guess it probably won't be TARGET_BUILTIN_SETJMP_FRAME_VALUE then. You only
need it if your stack frames have unpredicatable gaps in them so that you can't
--- Comment #21 from dave dot korn dot cygwin at gmail dot com 2009-01-26
19:03 ---
Hi Joey, thanks for helping look at this bug.
If you catch up with all the comments, you'll see that it's not just Cygwin,
SjLj was broken on Linux too; the mechanism works the same way on both
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-01-31
18:53 ---
Bug fixed.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
--- Comment #12 from dave dot korn dot cygwin at gmail dot com 2009-03-25
08:03 ---
Hi all.
This patch caused g++.dg/ext/dllimport7.C to regress (in one subtest) between
4.3.2 and 4.3.3 on Cygwin, although it could be that the testcase is out of
date.
// { dg-do compile { target i?86
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-03-29
17:47 ---
For Cygwin, we just recently made --enable-auto-import the default in CVS
binutils. Now that we're moving to shared library runtimes throughout it made
sense.
However, I think this is a real bug
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-04-22
11:20 ---
Hi Rob,
I just ran into this on i686-pc-cygwin. I think the reason you see it on
some builds and not others is because of the --enable-libgcj-debug option;
presumably that makes the asserts
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-04-22
11:22 ---
Created an attachment (id=17671)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17671action=view)
Fix debug asserts.
Adjust the assert to test the casted pointer.
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-04-22
11:24 ---
That gets me about three files further through the build, then there's another
failure:
In file included from
/gnu/gcc/gcc/libjava/gnu/classpath/natConfiguration.cc:17:
/gnu/gcc/gcc/libjava/gnu
--- Comment #8 from dave dot korn dot cygwin at gmail dot com 2009-04-22
11:34 ---
Yep. From the .ii file:
class gnu::classpath::Configuration : public ::java::lang::Object
{
Configuration();
static ::java::lang::String * classpath_home();
static jboolean debug();
static
--- Comment #9 from dave dot korn dot cygwin at gmail dot com 2009-04-22
22:38 ---
Created an attachment (id=17679)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17679action=view)
Part two of fix
This renames the DEBUG macro to __GCJ_DEBUG throughout. It fixed the build in
my
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-04-27
21:39 ---
I just got this failure during bootstrap:
libtool: compile: /gnu/gcc/obj3/gcc/gcj
-B/gnu/gcc/obj3/i686-pc-cygwin/libjava/ -B/gnu/gcc/obj3/gcc/ -ffloat-store
-fomit-frame-pointer -Usun -fclasspath
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-04-28
03:30 ---
(In reply to comment #4)
I just got this failure during bootstrap:
I'm going to try reverting r146831 locally and see if it helps.
Doing so allowed the build to complete. See also bug 39932
: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-05-08
11:53 ---
Created an attachment (id=17826)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17826action=view)
Simple testcase
It doesn't get much more trivial than this.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-05-08
11:55 ---
To reproduce the bug, compile the attached testcase
g++-4 -fpreprocessed -S vti.ii
and view the very end of the .s file emitted:
.section .drectve
.ascii -export:_ZTV12XMLException
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-05-10
01:11 ---
Created an attachment (id=17841)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841action=view)
inherit dllexport from class to typeinfo
Now testing a solution based on the approach of adding
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-05-10
11:17 ---
(In reply to comment #4)
Hello Dave,
Hi Danny!
Rather than use DLL linkage (and so force client to resort to auto-import
magic)
why not just always emit the RTTI with one-only comdat linkage
--- Comment #54 from dave dot korn dot cygwin at gmail dot com 2009-05-14
06:25 ---
I've started work on the binutils support for this. Work-in-progress patch at
http://sourceware.org/ml/binutils/2009-05/msg00228.html
Once that's complete, I could deal with the GCC end too.
What
--- Comment #56 from dave dot korn dot cygwin at gmail dot com 2009-05-20
04:25 ---
Created an attachment (id=17895)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17895action=view)
Target option and autoconf test to enable aligned common support.
Currently putting the attached
--- Comment #57 from dave dot korn dot cygwin at gmail dot com 2009-05-20
21:16 ---
Bah. In case anyone else was about to point this out to me,
+gcc_GAS_CHECK_FEATURE([.comm with alignment], gcc_cv_as_comm_has_align,
+ [2,19,52],,
+ [.comm foo,1,32],,
+[AC_DEFINE
--- Comment #58 from dave dot korn dot cygwin at gmail dot com 2009-05-23
11:46 ---
Created an attachment (id=17906)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17906action=view)
Revised patch
Revised version of the patch that defines the autoconf feature test macro to
0/1
--- Comment #59 from dave dot korn dot cygwin at gmail dot com 2009-05-23
14:08 ---
Created an attachment (id=17909)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17909action=view)
D'oh. Quick respin.
Huh. Alignment is passed to the backend as number of bits, but of course
korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40309
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:01 ---
It's not entirely straightforward, it seems. An earlier attempt appears to
have fizzled out:
http://gcc.gnu.org/ml/fortran/2007-09/threads.html#00289
I do not yet understand Andrew Pinski's objection
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:19 ---
About to test this:
$ svn diff -x -p fortran/trans-decl.c
Index: fortran/trans-decl.c
===
--- fortran/trans-decl.c(revision
--- Comment #4 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:34 ---
(In reply to comment #3)
About to test this:
That was wrong. This is what I should have said:
$ svn diff fortran/trans-decl.c
Index: fortran/trans-decl.c
--- Comment #5 from dave dot korn dot cygwin at gmail dot com 2009-05-30
15:38 ---
The patch in comment 4 works.
dkad...@ubik /tmp/fortran
$ ./hello-fixed.exe
Hello World!
dkad...@ubik /tmp/fortran
$ gdb ./hello-fixed.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C
--- Comment #6 from dave dot korn dot cygwin at gmail dot com 2009-05-30
16:12 ---
Groan.
PASS: gfortran.dg/Wall.f90 (test for excess errors)
spawn [open ...]
Internal Error: insert(): Duplicate key found!
FAIL: gfortran.dg/Wall.f90 execution test
In other words, exactly what Andrew
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-05-30
17:09 ---
http://gcc.gnu.org/ml/fortran/2009-05/msg00452.html
We have two functions that both match MAIN_NAME_P, because they share the same
DECL_NAME. This happens when there is a PROGRAM main directive
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-06-01
08:05 ---
I checked the fix and it works. Verified.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16
11:26 ---
Could you re-run that with --save-temps, and attach the .i, .s, .o and .exe
files to the PR please?
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-06-16
11:40 ---
Already fixed at r.148523, according to:
http://gcc.gnu.org/ml/gcc/2009-06/msg00339.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40456
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-06-25
15:37 ---
Hmm, I'm getting somewhere with this.
By compiling the g++ testsuite ptrflags.C case with --save-temps, manually
hacking all the superfluous typeinfo stuff out, and re-assembling and linking
it, I
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-06-29
15:12 ---
I think the best solution to this problem is to enable libstdc++ as a DLL, and
export _S_empty_rep from it. Then every C++ DLL and EXE will link against
libstdc++ and they'll all import the exact same
--- Comment #64 from dave dot korn dot cygwin at gmail dot com 2009-07-04
12:47 ---
(In reply to comment #63)
GCC still generates a segfaulting executable when used with the testcase in
the
report, most likely because my assembler doesn't support the 3-argument .comm
directive
--- Comment #66 from dave dot korn dot cygwin at gmail dot com 2009-07-04
13:21 ---
(In reply to comment #65)
Indeed, i should have expected this, and after rereading the comments here you
even mentioned this problem already. Sorry for the noise.
That's OK. GCC attempts to detect
--- Comment #15 from dave dot korn dot cygwin at gmail dot com 2009-07-04
23:27 ---
(In reply to comment #14)
I am on cygwin-1.5. will these fixes get pushed to setup? or am I stuck? or
is
there a work around?
Hi Jerry,
I can't answer that question. There is a new binutils
--- Comment #17 from dave dot korn dot cygwin at gmail dot com 2009-07-04
23:55 ---
It is beta, yeah. But it's a damn good beta :) Can't promise you won't
stumble across a new bug or two, but it's reliable enough for fairly heavy-duty
everyday usage.
--
http://gcc.gnu.org
--- Comment #20 from dave dot korn dot cygwin at gmail dot com 2009-07-05
23:47 ---
(In reply to comment #19)
(In reply to comment #18)
As Dave suggests in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40455#c13,
this
is fixed,
I tried it yesterday, after updating with SVN
: dave dot korn dot cygwin at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-07-19
17:50 ---
(In reply to comment #0)
I notice that ffi_call_SYSV has to handle all the return types, but not
ffi_closure_SYSV nor ffi_closure_raw_SYSV. Does anyone know why that is?
To answer my own question
83 matches
Mail list logo
