loadlib and libraries with '.' in the name

.local pmc lib_gtk
lib_gtk = loadlib "libgtk-x11-2.0"

the problem is the '.' in the library name. code was added to src/
dynext.c in 8209 that gets the lib_name, the name of the library
without any prefix or leading path information. this fix breaks the
ability to load libraries with .'s. the offending code is:

ext_start = strrchr(*lib_name, '.');
if (ext_start)
*ext_start = '\0';

which finds the last '.' in the library name and sets it to the null
char if one is found, thus turning libgtk-x11-2.0 in to libgtk-x11-2
which can't be found. this results in an unable to load libgtk-
x11-2.0 with an "unknown reason" message.

if i set ext_start to NULL just before the test and null char set and
the library loads fine.

i'm not really sure what the solution here would be. you'd have to
know what all of the possible extension types were and look to remove
them if found otherwise you have no idea what is and isn't just part
of a library name. in what situation would you be passing in a full
path and file with extension to loadlib? is that a requirement to be
able to? it sound unnecessary to me. i'm willing to implement and
test any ideas/suggestions people have.

i was planning on playing around with gtk+ bindings and parrot and
went about looking around for the work that had already been done and
didn't turn anything up. if anyone knows where i can find it or who i
should talk to i would appreciate that info as well.

-rm

On Fri, 23 Sep 2005 15:51:31 +1000, Ross McFarland <rwm...@neces.com>
wrote:

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

my first thoughts were not to do that much tear up for fear of fixing
this bug, but introducing others. i'm in the processing of thinking
through how something like that would go now. provided that i come up
with something a patch will be forthcoming. i suppose i'll put it in
the bug tracking system unless someone tells me otherwise.

-rm

On Fri, 23 Sep 2005 16:10:32 +1000, Ross McFarland <rwm...@neces.com>
wrote:

>

--

cross platform it would be tough b/c you need to know the full path
to something you can load. i've got a testcase that given a lib's
full path info it tests all possibilities. i guess it could just use
something like libm with the hardcoded path of /usr/lib/libm.so and
skip the test if that file doesn't exist. that would test on a good
portion of systems which is better than not testing anything just
because you can't on all systems.

-rm

Does it help to use libnci_test? That's what t/pmc/nci.t uses. (It's
late and I've only skimmed the code right now, so it may not be
helpful.)

-- c

good idea, provided that i can get the full path to it so that i can
test all of the permuitations it would work.

i have all of the native \ / cases handled. i've got a little bit
more work to do for handling things coming in as in the opposite \ /
than the system we're running on. there's also a really hacky win32
thing tacked on the end that removes the lib from the front, but it
would only work for cases without a path. i can do the same, but
that's pretty broken as is and it would seem you'd need to do the
opposite if the lib was specified in win32 speak and you're running
on unix-y system. there's a fixme comment saying that stuff probably
belongs in somewhere else and i might look in to that, but i'll
probably stick to reproducing the current behavior first.

bed time for now, i'll get back to this tomorrow.

-rm

The need for such libnames arises typically on debian and alikes, where
not all -devel packages are installed. I see two possibilities here:
1) demand from user to either install the -devel pkg or symlink the
shortname
2) Parrot stops trying to ...

... strip extensions.

Google for "NCI gtk". There is also a weekly summary entry but the
xrl.us shortcut seems to have expired.

> -rm

leo

> > found...

How about removing the extension only if the rightmost dot is followed
by a letter?

Regards,
Roger Browne

Jonathan

yeah and no, it's native as in C not really platform. something like
libm would be a good, though trivial, example. it's likely on every
system you come across and if you want to get at something in it you
should be able to. there's nothing platform specific about libm other
than the file name. if we allow to code to say either

loadlib libm
or
loadlib m

then bindings for it would work on any platform that had lib m. i'm
all for not trying every perm, in fact there's several of them that
aren't handled in the current code as it stands. i think the real
solution is to define what loadlib expects more thoroughly so that a
reasonable and completely set of things can be attempted.

-rm

that would solve the gtk case, but you can still envision legal
library names that break this.

loadlib liborg.perl.something

that's a perfectly legal, albeit weird, library name.

-rm

as my original email mentioned i think all of this try everything
possible permutation is hacky and not a good idea. i think the real
solution is to require that loadlib only gets the stem of the
library. we can then reliably put on the appropriate extension for
the platform and go about the normal searching stuff. if we know we
always get the prefix we can also safely and correctly do the win32.
if you look at the doc for loadlib it talks about library names, not
files with paths with and without extensions. all of the examples are
name only as well.

i think that library name (without extension and with or without lib
on the front) is the best route. the doc almost already says as much,
and i can extend it to be more explicit. we could cleanly handle all
of the cases then. i don't want to make the decision for everyone.

-rm

I was wondering about that. I Googled for "tinyurl considered harmful"
and was surprised to find only one message, discussing the phishing
risks. I found no mention of the risk of outsourcing a bottleneck to a
third party who has zero obligation or direct interest to continue
providing the service.

From <http://metamark.net/about#expire>:

> Do Metamark links expire?
>
> The Metamark urls expire after five years or two years after the last
> usage - whichever comes later. However, if a link is never used, it
> will expire after two years. This should mean that as long as a link
> is on a public page, some search engine will visit it and keep it
> alive.
>
> Of course, this is subject to change and is no promise but just my
> intentions as of this writing. If you want guarantees you can make
> your own service.

To be quite frank, I'm astonished the practice exists here in the first
place. In my opinion it goes directly against the spirit of the Web
envisioned by Tim Berners-Lee. A better practice would be to post long
URL's within angled brackets. And there's no reason you can't do both,
either.

Josh

for those of you interested:
https://rt.perl.org/rt3/Ticket/Display.html?id=37258

i'll work on porting the pir to a .t test at some point if that would
be desirable.

later,
-rm

This patch seems to simplify things. Two remarks:
- use mem_sys_allocate() instead of malloc - it deals w out-of-mem
- I don't understand the extra check:
+ if (path)
+ goto done;

Tests are very welcome albeit a bit non-trivial as platforms and
availability of libs most be taken into account.
>
> later,
> -rm

leo

i was only using what was there before. this is the first time i've
touched parrot and don't yet know anything about it outside of that
file.

extra as in one last or extra as in why i'm checking at all?

the reason i went ahead and put it on the last one was so that other
tries could be put in on the end without breaking that one, it
doesn't hurt to do the extra goto.0

the reason i'm doing that in the first place was just to quit trying
and unify the cleanup code.

it's been suggested that i use libcni_test which will always be
around. that should work, but it still will probably be somewhat
complicated.

-rm

The test 'if (path)'. Before that is an 'if' that checks, if library
loading was ok. Therefore I don't understand this line. The goto to the
cleanup part is fine.

> -rm

leo

oh, crap, heh. i used to have a function called try_load that was
called in place of the actual load and the if path's checked it's
return value. when i realized i didn't want to be calling the runtime
stuff that function shrunk to almost nothing. i got rid of the
function and put the remaining code in it's place as the last thin i
did before submit the original patch. i guess i didn't look close
enough at the result of that. new patch attached shortly resolving
the oversight.

thanks,
-rm

. . .

-rm

See also the loadlib tests in t/dynclass/foo.t. Tests 2-5 load
"runtime/parrot/dynext/foo" in various permutations, with suitable magic
for platform independence.

-- Bob Rogers
http://rgrjr.dyndns.org/

Which is why the archived summaries at deve.perl.org and perl.com all use the
long form URLs. The metamarked URLs only ever appear as a convenience for
readers on the mailing list. I am not about to start polluting my mailed
summaries with such monstrosities as

<http://groups.google.com/groups?threadm=rt-3.0.11-37067-120...@perl.org>

any time soon. You're welcome to write your own summaries that do use the full
URLs of course. Or, if it bothers you that much, write something to run from
cron once a month or so that grabs shortened summary URLs and does a simple GET
on them.

--
Piers Cawley <pdca...@bofh.org.uk>
http://www.bofh.org.uk/

Then again who knows how long google group links will be good for.

A summary is only a summary. It doesn't need to be good for ever.
That is what rt/design docs/people are for.

--
It is our job to proactively build progressive technology so that we may
endeavor to authoritatively facilitate quality products while maintaining
the highest standards

[...]

If I found the same link you found then it's not the xrl.us shortcut -
http://xrl.us/cw78 - but the Google group link that stopped working.

The use case for the Metamark service was actually to have a "short
links" service for the perl list summaries (and for the perl community
in general) to use that's not "outsourced". (Metamark is running on a
server a few feet above the servers your mail went through to go out
to the list subscribers).

[...]

> first place. In my opinion it goes directly against the spirit of [...]

Are you talking about expiring links or putting the short links in the
mails that go out?

Apart from the occasional phishing link then we haven't actually
expired any of the metamark urls yet.

I did some random spot checks on old short URLs used in the summaries
and they get used regularly[1] so even if/when we start expiring
unused links in a few years they won't go away.

[1] by humans or bots, I don't know - for your privacy we don't track
more than a daily count.

- ask

--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();