Sebastian Reitenbach wrote:
For me the Bundle binary is a shared object, and no a standalone
binary. I
cannot just run it. For me, a shared object usually has a .so
extension.
So I still don't know why it is not a good idea to have .so
extension for
Bundle binaries.
It is not a good idea because it just adds one more platform
dependency, making the code less maintainable. Note that not all
systems are using the .so suffix, e.g., I'm sitting right now in front
of an OS X machine which does not use an extension for bundle
executables (maybe not very surprising) and which uses .dylib instead
of .so for shared libraries. On AIX, where all objects are position
independent by default shared libraries use the extension .a (sic!).
Still other systems were using .shlib for shared libraries. Tracking
these differences is just adding needless complexity given that we can
simply load the bundle executable from a file with any extension or no
extension at all.
I guess there were some reasons, when it was decided how they have
to look
like, and don't want to question that, but rather understand why it
is the way
it is, since I don't see the reason, yet, and why there is an
exception
explicitly for Windows?
I guess its because Windows refuses to load the shared object if it
does not have the proper extension, but then I'm not a Windows expert.
Wolfgang
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
