Re: New 'back' backend
Hi Nicola, for your fix in the bundle make file you added a comment that we should explain, why we have to link against all libraries on Windows while we don't need this on any other system. The reason is simple, we don't need this on Windows either. What we need there is that we define a pre-processor variable XXX_ISDLL for all the DLLs we include. And this definition is currently connected to the same variable that is used for the libraries to link against. What we should do now is split up this two different uses. And if possible let the later be handled by a general rule for all different forms of projects (There is already a rule for this in rules.make, but somehow it only works for libraries). It was my fault to overlook the harm that could come from uncommenting that line in the bundle make file, but as my knowledge of the GNUmake mechanism is only marginal, I am surely not able to implement the correct solution, which we have been discussing in private mail for almost a month now. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: New 'back' backend
that occurred to me too ... and well it is certainly caused by the fact that gnustep-make has been modified to link bundles against all libraries So does that mean that it staticly links bundles against available libraries rather than using the shared libraries on startup ? I am somewhat confused by this comment... -bat. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: New 'back' backend
that occurred to me too ... and well it is certainly caused by the fact that gnustep-make has been modified to link bundles against all libraries So does that mean that it staticly links bundles against available libraries rather than using the shared libraries on startup ? I am somewhat confused by this comment... I mean that ... well that if your main application is linked against gnustep-base (linked statically or sharedly, whatever), and your main application loads a bundle, that bundle does not need to be linked itself against gnustep-base - because gnustep-base is already linked in the main application. The bundle is only used when loaded by the application, where gnustep-base is already linked in -- so there is no need to have gnustep-base linked in the bundle too. Previously, we didn't link anything in the bundle, unless the programmer explicitly asked for a library to be dragged in (loaded) when the bundle was loaded. Typical example - your bundle uses a database-specific database client library; you link your bundle explicitly against that library, while the main application does not need to link against it; and when the bundle is loaded, the database library is taken in. All other libraries are normally already in the main application, so there is no need to try and drag them in too when the bundle is loaded. Currently, we instead link all libraries required to build an executable into every bundle too. That may cause problems ... or may not -- but it makes things more complex -- just think what happens if you have your application linked to a version of gnustep-base, and your bundle linked to another version :-) ... I'm no expert of static libs, but I suspect static libs being linked twice might cause additional problems. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: New 'back' backend
Ahh, I get it... was this change made to support Windows by any chance ? One of the big problems with Bundles on the old OpenSTep forNT was that you culdnt call anything from the main application that you needed to link against - it all had to be linked into the bundle separately. This might be my problem-has anybody tested the new code on FreeBSD yet, or am I the fiirst ? I get the impression that most people are using Linux. I'll compile it up tomorrow and see if I can find out where the coredump is happening. thanks, -bat. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: New 'back' backend
having done that I now get a coredump. that occurred to me too ... and well it is certainly caused by the fact that gnustep-make has been modified to link bundles against all libraries ... that change is delicate and probably needs to be fixed somewhat ... problem is understanding all the bits - perhaps it might be turned on on windows and off on all other platforms. anyway - now it works on my machine. I both fixed a bug in gnustep-gui, which was linking the TextConverter/RTF bundle with the installed gnustep-gui rather than the one being compiled, and switched my system to use a shared libobjc again. I'm not sure what exactly made the difference, but one or the other or both of these changes fixed the core dump. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
