Hi Patrick,
Patrick Hartling wrote:
>No, I didn't try that. I could pursue that if you want to know the results,
>but it will take a bit longer than the simpler tests that I did.
>
>
That's fine, I was just curious.
>In general, yes. I think that if there are going to be more arguments to
Dirk Reiners wrote:
> Hi Patrick,
>
> On Fri, 2006-08-18 at 09:11 -0500, Patrick Hartling wrote:
>> Yes, this is generally the case in my experience. Explicit references to
>> symbols in applications are supposed to be resolved at link time. Plug-ins
>> to C++ applications are best suited fo
Dirk Reiners skrev:
> Hi Marcus,
>
> On Fri, 2006-08-18 at 16:50 +0200, Marcus Lindblom wrote:
>> Wouldn't you have to go pretty low-level in order to make osgInit() call
>> the OS's dynamic linker to resolve things? I've never heard of anything
>> like it being done ever before. (If that
Hi guys,
ok, back to the roots now.
On Fri, 2006-08-18 at 08:07 -0500, Allen Bierbaum wrote:
>
> I don't think I clearly said why we were thinking about this. I know I
> could do this in my applications, but I wanted to see if there was
> interest in having OpenSG use it for it's own
Hi Patrick,
On Fri, 2006-08-18 at 09:11 -0500, Patrick Hartling wrote:
> Yes, this is generally the case in my experience. Explicit references to
> symbols in applications are supposed to be resolved at link time. Plug-ins
> to C++ applications are best suited for accessing abstract inter
Hi Marcus,
On Fri, 2006-08-18 at 16:50 +0200, Marcus Lindblom wrote:
>
> Wouldn't you have to go pretty low-level in order to make osgInit() call
> the OS's dynamic linker to resolve things? I've never heard of anything
> like it being done ever before. (If that is what is being sugges
(I hope I haven't misunderstood what you're shooting for, if so, much of
this might not make sense.)
Patrick Hartling wrote:
> Dirk Reiners wrote:
>> Hi Allen,
>>
>> On Thu, 2006-08-17 at 21:34 -0500, Allen Bierbaum wrote:
>> To sum it up: could work, but would require support by the OS.
>
Hi,
regarding all these talks about breaking up the library and dynamic
linking via dlopen etc. I am not quite sure if this is really that big
problem. I for myself would be more than happy if the big system
library would be simple split into things like:
Image
Nodes
Network/Cluster
Traversal
Dirk Reiners wrote:
> Hi Allen,
>
> On Thu, 2006-08-17 at 21:34 -0500, Allen Bierbaum wrote:
>> Having OpenSG do it internally. My (possibly naive) approach would be
>> to scan a given plugin path and load all the .so/.dll files in that
>> directory. This would be similar to how other sy
Allen Bierbaum wrote:
> Dirk Reiners wrote:
>> Well, it would work for all objects that are explicitly linked to the
>> application. I don't think the run-time linker would let you start a
>> program without being able to resolve all symbols, but I might be wrong
>> about this. If it does let you,
Allen Bierbaum wrote:
> Andreas Zieringer wrote:
>
>> Hi Allen,
>>
>> hmm perhaps I don't get this but this is already possible with OpenSG 1.x.
>>
>>
> I don't think I clearly said why we were thinking about this. I know I
> could do this in my applications, but I wanted to see if there was
Dirk Reiners wrote:
> Hi Allen,
>
>On Thu, 2006-08-17 at 21:34 -0500, Allen Bierbaum wrote:
>
>
>>Having OpenSG do it internally. My (possibly naive) approach would be
>>to scan a given plugin path and load all the .so/.dll files in that
>>directory. This would be similar to how other
Andreas Zieringer wrote:
>Hi Allen,
>
>hmm perhaps I don't get this but this is already possible with OpenSG 1.x.
>
>
I don't think I clearly said why we were thinking about this. I know I
could do this in my applications, but I wanted to see if there was
interest in having OpenSG use it for
> We were sitting around talking today before lunch about OpenSG 2.0 and
> the split to use a larger number of small libraries to help link
> speed.
what about load time and debugging?
> As an aside, using something like "FCFactory::create("Geometry")"
> would
> not really help the usabil
Hi Allen,
hmm perhaps I don't get this but this is already possible with OpenSG 1.x.
My own image and geometry loaders, chunks, nodes whatever are compiled
in several shared libraries. Now just link your app against this shared
libraries or if your app has no dependency to the shared library (e.
Hi Allen,
On Thu, 2006-08-17 at 21:34 -0500, Allen Bierbaum wrote:
>
> Having OpenSG do it internally. My (possibly naive) approach would be
> to scan a given plugin path and load all the .so/.dll files in that
> directory. This would be similar to how other systems do it so I think
Dirk Reiners wrote:
> Hi Allen,
>
>(I'll answer to the big mail later. Big mail answers take a little more
>time. ;)
>
>On Thu, 2006-08-17 at 17:08 -0500, Allen Bierbaum wrote:
>
>
>>We were sitting around talking today before lunch about OpenSG 2.0 and
>>the split to use a larger number
Hi Allen,
(I'll answer to the big mail later. Big mail answers take a little more
time. ;)
On Thu, 2006-08-17 at 17:08 -0500, Allen Bierbaum wrote:
> We were sitting around talking today before lunch about OpenSG 2.0 and
> the split to use a larger number of small libraries to help link
We were sitting around talking today before lunch about OpenSG 2.0 and
the split to use a larger number of small libraries to help link speed.
One of the problems that this causes is that applications need to know
more libraries to link against. As we talked more we started wondering
whether
19 matches
Mail list logo
