octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #55363] Global variable in a MEX file


From: Guillaume
Subject: [Octave-bug-tracker] [bug #55363] Global variable in a MEX file
Date: Fri, 4 Jan 2019 06:11:40 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Follow-up Comment #6, bug #55363 (project octave):

mexVersion seems to be an old symbol that does not exist any more. The nm
output in comment #1 was from a MEX file compiled with an old version of
Matlab:


nm -g -D -C --defined-only test.mexa64
0000000000000000 A MEX
0000000000000770 T mexFunction
00000000000007eb T mexVersion


A recent build gives:


nm -g -D -C --defined-only test.mexa64
0000000000000000 A MEX
0000000000000810 T mexfilerequiredapiversion
0000000000000790 T mexFunction


so it seems that we could only export the mexFunction symbol and match Matlab
behavior.

Using the static keyword would solve the issue here but, to my understanding,
there would still be a potential issue for MEX files corresponding to, e.g.,
wrappers to other libraries as they would necessarily contain non-static
functions (unless there is a way to specify that these functions shouldn't be
exported further from the file containing the mexFunction definition). That's
the point made in comment #5?

Looking further on Ubuntu, it seems that the difference in behavior is due to
the link flag -Bsymbolic-functions as I then manage to reproduce the issue on
openSUSE after adding it manually.

https://stackoverflow.com/questions/7216973/

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55363>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]