>>If you mean in app_kit/source/lib/support/src, then there is only a
>>329 byte sized placeholder.
>Oops. My mistake. :P
In fact, the migration scripts move the various support kit classes from
the storage kit tree and put them in the support kit tree. Thanks to
the storage kit guys for putting these together.
>>Err, no, I just thought, we couldn't link against libbe as we define
the
>>same symbols as libbe, and I reckoned, that the linker wouldn't eat
it.
>>
>>CU, Ingo
>You're right about the linker complaining about them. We've run into
that
>type of problem before with implementing the regular classes. IIRC,
Erik has
>said we no longer are using namespaces to resolve symbol conflicts.
Have you
>considered looking into just using (slightly) modified class names,
i.e.
>OBOSApplication instead of BApplication, etc.? I've done similar tricks
with
>the prototypes' test applications which are a very skeletal version of
>BApplication. That way, you can do a global replace on the string when
you
>have it to the point where you don't need libbe. It's just a thought -
you
>might have a different route in mind.
I sent out a mail a while ago talking about this. I discovered that you
can link against two libraries with the same symbols -- the loader will
load identical symbols from whichever library is first in the link line
(I've done this with libopenbeos.so and libbe.so). Hopefully this won't
be an issue for too much longer. =)
e
Necessity is the plea for every infringement of human freedom. It is the
argument of tyrants; it is the creed of slaves.
-William Pitt, British prime-minister (1759-1806)