[gambit-list] executable works, loadable module segfaults

REPLeffect repleffect at gmail.com
Sat Sep 29 22:32:00 EDT 2012


Yup.  That did it. Even went back to the original code for converting
from QStrings and all is well, just so long as I leave out the
-fno-keep-inline-dllexport from Gambit's compile and the loadable
library's compile.  Having that option in the Qt build doesn't seem to
matter.



On 9/29/12, REPLeffect <repleffect at gmail.com> wrote:
> For the sake of completeness, I thought I would update this again.
>
> Turns out that the -fno-keep-inline-dllexport is necessary to get Qt
> to compile under MinGW's 4.6.2 g++ compiler.  Evidently all of those
> inline dllexport function attribute definitions cause serious object
> bloat and cause the compiler to run out of memory.  Here's a quote
> from the gcc docs (section 6.30 "Declaring Attributes of Functions"):
>
> "In previous versions of GCC, the dllexport attribute was ignored for
> inlined functions, unless the -fkeep-inline-functions flag had been
> used. The default behaviour now is to emit all dllexported inline
> functions; however, this can cause object file-size bloat, in which
> case the old behaviour can be restored by using
> -fno-keep-inline-dllexport"
>
> I find it interesting that the old compiler (4.4.5) does not cause the
> problem I experienced, but yet adding the option that is supposed to
> restore the old compiler's behavior for the new compiler (4.6.2)
> *does* cause the problem.
>
> I was going to rebuild Qt (currently using 4.7.4) to take out the
> -fno-keep-inline-dllexport option, in case linking against Qt DLLs
> with that option might cause the same problem I had in my test program
> (which was *not* linked with Qt's DLLs).  However, Qt won't compile
> successfully with g++ 4.6.2 from MinGW without that option.
>
> I haven't yet tried to build an loadable library which is linked with
> Qt's DLLs against the Gambit library which was compiled without
> "-fno-keep-inline-dllexport".  I kind of suspect that this scenario
> will work, since the problem seemed to be with Gambit's library being
> compiled that way.  At the moment I'm building Qt *with*
> -fno-keep-inline-dllexport just to get it back the way it was.  I'll
> try to report back later on what I discover about a Qt-linked loadable
> library.
>
> I would be interested to know why the -fno-keep-inline-dllexport
> option causes a problem for Gambit.  I'm sure I don't have enough
> understanding of the inter-workings of Gambit to figure it out myself,
> but I'd be willing to try to help as much as I can to help determine
> the cause.
>
> REPLeffect
>



More information about the Gambit-list mailing list