> >>>>I suppose I could try to hack the building system to have the > >>>>application's symbols exported etc ... (did I remember correctly that > >>>>someone did an attempt at that already ?) > >>> > >>>That sounds like the right thing to do. > >> > >>I agree. While I don't deny Gorm could use some reorganization of it's > >>files > >>and makefiles, I believe that a change to the make system to handle this in > >>the > >>general case is the best solution to this problem. > >> > >>I thank Nicola for making the changes to Gorm's makefiles to allow Gorm to > >>work > >>on Windows, but I believe that, for the sake of any other apps which may be > >>using weak symbols, that this needs to be corrected in gnustep-make. I will > >>leave Nicola's changes in, for the time being, until a fix to gnustep-make > >>is > >>made. > > > > > > There is no fix to do to gnustep-make ... I already "fixed" gnustep-make > > to export all application symbols to allow you to link loadable bundles to > > the symbols in the application ... what you have now is the final > > solution. > > > > The application is automatically exporting all symbols into a wrapper > > library ... the palette is linking against the wrapper library to access > > the symbols ... there is no other way to do things > > Well, this is only half correct. As of GCC4, there will be /real/ weak > symbol support (in all places, including under mingw).
OK ... good, I suppose we'll be able to upgrade/simplify our building system when the new toolchain stuff gets widespread. :) Thanks _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
