Kenny McCormack
unread,Apr 21, 2018, 3:45:52 AM4/21/18You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
Some of my extension libs depend on the ability to access symbols (i.e.,
either data objects or functions) in the core GAWK executable. Yes, this
is weird, but ...
Up through GAWK 4.1.4, I could do this, by the usual method of declaring
the object "extern" in the extension library. At runtime, when GAWK loads
my library, everything gets resolved and it all works.
However, I recently built 4.2.1 (with API version 2.0) on x86_64 and found
that this doesn't work. When I attempt to load the library (via @load in
the GAWK script), I always get a failure to load the library because of an
unresolved symbol. I.e., the loader cannot find the symbol. It also
doesn't work if I try to locate the symbol via dlopen()/dlsym() and
friends. I spent a fair amount of time on this (did eventually find a
workaround - see below); eventually I concluded that it was as if there was
a wall between the extension library and the main executable. A wall that
hadn't been there in the past.
So, my reason for posting is to ask the experts a) If this is indeed a
change in the new version of the API and b) If it was intentional and if
there is a fix/workaround?
P.S. I did find a workaround - at least for one specific case - but it is
ugly and not at all satisfying. The workaround allows me to call a
function in the GAWK executable from my library.
--
Modern Christian: Someone who can take time out from using Leviticus
to defend homophobia and Exodus to plaster the Ten Commandments on
every school and courthouse to claim that the Old Testament is merely
"ancient laws" that "only applies to Jews".