Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem with latest GAWK/latest extension API: Can't access symbols in the executable

20 views
Skip to first unread message

Kenny McCormack

unread,
Apr 21, 2018, 3:45:52 AM4/21/18
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".
0 new messages