Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


Yet another <sigh>

  • Doug Semler
    Doug Semler

    Amazing how some people forget that if you apply __declspec(dllexport) is applied to any export then only symbols declared as exports will be exported.

    Anyway, just an FYI, libobjc-2.dll is completely busted on any windows (mingw32, cygwin, and mingw64)  toolchain build, since for some reason, only a few data thunks are decorated…and the .def file isn't being used.

    Not that anyone uses Objective C or anything….:)

  • Kai Tietz
    Kai Tietz

    Well, this I know to well. And be suprised, I have to use Obj-C at work ;) But for it we use the libobjc provided by GnuStep, and it is working nicely. I didn't had any real intend to fix gcc's version and strangely nobody really complained about this broken runtime library there.


  • Doug Semler
    Doug Semler

    Yeah, anyway I was playing around with it.  So, once I fixed the build so that it used the .def file again, and fixed the def file itself (so that the old hash_ functions are removed and a couple exports are added and remove the LIBRARY line so that it works on the command line), I got the testsuite going pretty good.  But then, I noticed that the exception code didn't work.  Why, you may ask?  Well, it turns out the link of the libobjc-2.dll doesn't link the shared libgcc_s dll.  So the SJLJ code doesn't work.

    After a bit of digging around, I'm wondering…

    Why isn't 64 bit mingw libgcc line in the gcc specs file like linux's?   In other words,  why isn't it something like:

    %{mthreads:-lmingwthrd} -lmingw32 %{static|static-libgcc:-lgcc -lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc -lgcc_s }%{shared-libgcc:-lgcc_s%{!shared: -lgcc}}}} -lmoldname -lmingwex -lmsvcrt

    If exceptions are thrown across DLL boundaries, the shared gcc library is needed.  Right now, the mingw specs line only allows selection of the shared libgcc if -shared-libgcc  is passed explicitly on the command line.  This hurts in situations like libobjc-2.dll, in which files are compiled then linked using the gcc driver (not the g++ driver).  The gcc driver doesn't add -shared-libgcc (g++ does), which means that when linking objc objects into a dll, they won't work right. (This is just an example).  The linker will only pull in the dll if it's needed, just like on linux, so it makes sense to gin up the link like this, doesn't it??

    After compiling libobjc-2.dll with the appropiate exports AND linking it with the shared libgcc (just 32 bit test but you get the idea):

    Target is i686-w64-mingw32
    Host   is x86_64-pc-linux-gnu

                    === objc tests ===

    Running target wine32-sim

                    === objc Summary ===

    # of expected passes            1876
    # of expected failures          7
    # of unsupported tests          21
    /opt/devtools/x86_64-linux/bin/i686-w64-mingw32-gcc  version 4.5.1 20100414 (prerelease)  (GCC)

    Compiler version: 4.5.1 20100414 (prerelease)  (GCC) objc
    Platform: i686-w64-mingw32


  • Ozkan Sezer
    Ozkan Sezer

    Doug:  can you post the necessary fixes or send them to my personal mail address please?

  • Doug Semler
    Doug Semler

    I did a major oops and am reconstructing some things that I blew away by accident by rm -rf'ing the wrong directory the other day.

    for now http://github.com/tpaxatb/buildscripts is a git repo that I am building that is getting my buildscripts.  It also has patches in it that I applied to binutils and gcc….(and cloog-ppl to get it to work with ppl 0.11)

    I'll post the relevant objective C patches for the DLL as soon as I reconstruct it.

  • Ozkan Sezer
    Ozkan Sezer

    Sorry that you lost your data.

    Nice binutils patches in your repo, hopefully they'll help the zlib/msvc problem reported today in which case I would include them in my builds, too. (Will you submit them upstream, or is there a FSF copyrignt issue?)

    As for the objc stuff: I'll be keeping an eye on your repo.
    FYI, I also looked at the gnustep version (repo at http://svn.gna.org/viewcvs/gnustep/libs/libobjc/), they do:
    - implement some missing w32 thread stuff
    - add objc_DECLARE do malloc & co function pointers in misc.c (are these the ones that you say that were missing?)
    - and they disable dllexport for mingw alltogether (not exactly sure why, yet)

  • Doug Semler
    Doug Semler

    I'm having a minor issue with the disclaimer wording at work…and am trying to verify the wording they want to use is ok with the FSF people.

    I didn't touch threading -- one thing at a time :)

    IIRC, disabling dllexport isn't the right thing to do, because it will end up exporting all of the globals from the dll, which exports things from statics that are linked in.  The thing so far that I've reconstructed was:
        - Modify the .def file so that it doesn't have the LIBRARY declaration (so that the dllname is from the command line)
        - Modify the .def file so that it doesn't export the hash_* functions (since they no longer exist)
        - Modify the .def file to add a couple of missing things (objc_layout_structure_*, objc_exception_throw, __gnu_objc_personality_sj0
       - Add -export-symbols $(srcdir)/libobjc.def back to the extra_ldflags in the configury

    I think that's all i did.  I'm rebuilding right now to see if I got it all.

    I still am unsure about the specs changes.  -shared-libgcc is required when building the libobjc-2.dll so that exceptions can be thrown out of the dll.  In addition, it's required when -fobjc-exceptions is passed to the driver.  I don't know whether the best way is to modify the build of libobjc.dll with a specs file change (that basically follows the logic "if -fobjc-exceptions and !-static then add the flag -shared-libgcc to the link" or if the best way is to modify the specs completely to follow the logic that I put above.  The problem is that the logic above works on linux (it does "the right thing ™" because of DT_NEEDED of dependencies….which PE-COFF doesn't have…IOW there's no way to determine at link time whether any of the dependencies being linked require the shared libgcc - which is really what is needed…..

  • Doug Semler
    Doug Semler


    I uploaded the patch to my github repo mentioned earlier in the gcc4.5-patches subdir.  It should apply to 4.6 as well.

    I specifically targeted only the w64 build in it because I can't regress it on the other windows targets…I'm currently running the tests for the x86_64-mingw32 side…but it's passed all the tests thus far…*including* the exceptions.exp tests…

    One thing that I had to do is before I ran the testsuite, I need to add the following two lines to the end of /path/to/build/gcc/site.exp (if they don't already exist), which also solves quite a few other testsuite compiler failures.  If we can figure out how to add these flags all the time for the target testsuite then we'd be golden….the message generated by the linker during the compile phase causes a lot of failures when linking to dllexported DATA…which is alot of C++, and quite a bit of ObjectiveC

    ## All variables above are generated by configure. Do Not Edit ##
    append CFLAGS_FOR_TARGET "-Wl,-enable-auto-import"