Richard Harke <[EMAIL PROTECTED]> writes:
> On Sunday 27 June 2004 07:18 pm, Alex Romosan wrote:
>> Richard Harke <[EMAIL PROTECTED]> writes:
>> > In dlfcn.h we find:
>> > /* Unmap and close a shared object opened by `dlopen'
>> >The handle cannot be used again after calling `dlclose'. */
>>
On Sunday 27 June 2004 07:18 pm, Alex Romosan wrote:
> Richard Harke <[EMAIL PROTECTED]> writes:
> > In dlfcn.h we find:
> > /* Unmap and close a shared object opened by `dlopen'
> >The handle cannot be used again after calling `dlclose'. */
> > extern int dlclose (void *__handle) __THROW;
> >
Richard Harke <[EMAIL PROTECTED]> writes:
> In dlfcn.h we find:
> /* Unmap and close a shared object opened by `dlopen'
>The handle cannot be used again after calling `dlclose'. */
> extern int dlclose (void *__handle) __THROW;
>
> Also RTLD_DEFAULT is a gnu extension and requires
> __USE_GN
On Sunday 27 June 2004 03:28 pm, Alex Romosan wrote:
> Frederic Bouvier <[EMAIL PROTECTED]> writes:
> > Alex Romosan wrote:
> >> "Frederic Bouvier" writes:
> >> > The fact that you are using the function pointer *after* dlclose
> >> > is as broken as Erik's version. This is not good practise to
> >
Frederic Bouvier <[EMAIL PROTECTED]> writes:
> Alex Romosan wrote:
>
>> "Frederic Bouvier" writes:
>>
>> > The fact that you are using the function pointer *after* dlclose
>> > is as broken as Erik's version. This is not good practise to
>> > bet on side effects that are beyond your control.
>>
Alex Romosan wrote:
> "Frederic Bouvier" writes:
>
> > The fact that you are using the function pointer *after* dlclose
> > is as broken as Erik's version. This is not good practise to
> > bet on side effects that are beyond your control.
>
>
> _NO_, because the pointer now points to an objec
"Frederic Bouvier" <[EMAIL PROTECTED]> writes:
> The fact that you are using the function pointer *after* dlclose
> is as broken as Erik's version. This is not good practise to
> bet on side effects that are beyond your control.
_NO_, because the pointer now points to an object in memory in th
Alex Romosan <[EMAIL PROTECTED]> writes:
> "Frederic Bouvier" <[EMAIL PROTECTED]> writes:
>
>> I was not understanding Erik point of view of advocating a patently
>> broken code but now I am really missing your point :-(
>
> i just posted a fix which should work on both linux and irix (and any
>
Alex Romosan wrote:
> Erik Hofman <[EMAIL PROTECTED]> writes:
>
> > Alex Romosan wrote:
> >
> >> you are mixing static and dynamic linking. andy is talking about
> >> dynamic linking. i am not sure what you are talking about.
> >
> > Statically linking a shared-object library only means it gets
>
"Frederic Bouvier" <[EMAIL PROTECTED]> writes:
> I was not understanding Erik point of view of advocating a patently
> broken code but now I am really missing your point :-(
i just posted a fix which should work on both linux and irix (and any
other unix). i need somebody to test the irix part.
Erik Hofman <[EMAIL PROTECTED]> writes:
> Alex Romosan wrote:
>
>> you are mixing static and dynamic linking. andy is talking about
>> dynamic linking. i am not sure what you are talking about.
>
> Statically linking a shared-object library only means it gets
> dynamically linked upon program star
Alex Romosan wrote:
> "Frederic Bouvier" <[EMAIL PROTECTED]> writes:
>
> > Anyway, a fix is in CVS now
>
> not exactly. the "fix" is ugly beyond belief. it basically boils down
> to commenting out dlclose() (despite all that code being moved
> around). it also misses out a call to dlerror() afte
Erik Hofman <[EMAIL PROTECTED]> writes:
> I think I'm on to it.
After updating to today's CVS it flies again, better than ever,
thanks!
--
Istvan
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo
"Frederic Bouvier" <[EMAIL PROTECTED]> writes:
> Anyway, a fix is in CVS now
not exactly. the "fix" is ugly beyond belief. it basically boils down
to commenting out dlclose() (despite all that code being moved
around). it also misses out a call to dlerror() after dlopen() and
before dlsym() to cl
Does anyone here know a better way to get ac3d_export.py to recognize two sided
polys in blender other than going into face mode and individually selecting each
one and setting it to twoside in the texture face menu?
Josh
___
Flightgear-devel mailing l
Alex Romosan wrote:
you are mixing static and dynamic linking. andy is talking about
dynamic linking. i am not sure what you are talking about.
Statically linking a shared-object library only means it gets
dynamically linked upon program start. There is a way to do delayed
static linking, but tha
MD11MainBranch
MD-11.3ds
0
-25
-0.5
CockpitMainBranch
Aircraft/MD11/Models/cockpit/cockpit.xml
...
CockpitMainBranch
MD11MainBranch
...
It doesn't work. The XML parsing failed and I got the stupid glider. =(
I believe I have failed to understand your ex
Alex Romosan wrote:
> Erik Hofman <[EMAIL PROTECTED]> writes:
>
> > Andy Ross wrote:
> >> Erik Hofman wrote:
> >>
> >>>Since FlightGear is linked to libGL at link time, the number of
> >>>dlclose calls would always be one less than the number of dlopen
> >>>calls.
> >> In which case the dlclose()
Erik Hofman <[EMAIL PROTECTED]> writes:
> Andy Ross wrote:
>> Erik Hofman wrote:
>>
>>>Since FlightGear is linked to libGL at link time, the number of
>>>dlclose calls would always be one less than the number of dlopen
>>>calls.
>> In which case the dlclose() is 100% guaranteed to be a noop anyway
Jon Berndt wrote:
Ok. The first thing I will try is to see if I can get the PID
controllers to work correctly again. If that fails we can always look
further into it.
Something wierd is also going on with alpha that may have had to do with changes to
FGAuxiliary.
I think I'm on to it.
Further disc
> Ok. The first thing I will try is to see if I can get the PID
> controllers to work correctly again. If that fails we can always look
> further into it.
Something wierd is also going on with alpha that may have had to do with changes to
FGAuxiliary.
Jon
___
Jon Berndt wrote:
I might add that my changes were to fix things that really were broken.
Which might be the reason the F-16 is left broken right now. Maybe it
was relying on broken code too much in the past?
That thought did occur to me. I did correct the way some filters were done.
Pk. The firs
> > I might add that my changes were to fix things that really were broken.
>
> Which might be the reason the F-16 is left broken right now. Maybe it
> was relying on broken code too much in the past?
That thought did occur to me. I did correct the way some filters were done.
Jon
Andy Ross wrote:
Erik Hofman wrote:
Since FlightGear is linked to libGL at link time, the number of
dlclose calls would always be one less than the number of dlopen
calls.
In which case the dlclose() is 100% guaranteed to be a noop anyway and
can be safely removed. :)
Seriously: consider the case
Ampere K. Hardraade wrote:
> I meant, if in such XML file:
>
>
>
>
>
> MD-11.3ds
>
>0
>-25
>-0.5
>
>
>
>
> Aircraft/MD11/Models/cockpit/cockpit.xml
>
>
> ...
>
MainBranchOfCockpit
MainBranchOfMD-11
>
>
> How do I change the ordering of MD11.3ds and the mesh
Jon Berndt wrote:
Erik's F-16 has been around for a while, and working.
So, it may be some change I made
recently. There have been a few changes to the FCS.
Jon
I might add that my changes were to fix things that really were broken.
Which might be the reason the F-16 is left broken right now. Mayb
26 matches
Mail list logo
