Re: gEDA-dev: [PCB] feautre request: -rdynamic

[Igor2 <igor2-at-NOSPAMinno_dot_bme_dot_hu>]

On Sat, 30 Sep 2006, DJ Delorie wrote:

>
>> I hook fopen() from a loader lib injected using LD_PRELOAD. Originally I
>> hooked strrchr(), but it turned out that some systems have strrchr() as
>> macros.
>
>Ok, not portable ;-)

Yeah, it is an ugly hack to make it work until PCB has support for loading
hids :) I didn't think it would happen this soon.

>> If you plan to add native support in PCB so one doesn't need to use
>> such hacks, I think the simplest way would be to acquire the HID
>> names from a file and/or command line arguments and just load them
>> using dlopen() and call an init function. The init function then can
>> call back hid_register_hid() and co.
>
>I was wondering what to call the init function.

Ohh, like that. I used void hid_plugin_init().

>I was thinking, for "foo.so" I'd first check "hid_foo_init()" and,
>failing that, "init()".  Can't use "hid_init()" because that's a
>function in pcb itself.
>
>I'd go with just "init" for everyone, so that renaming .so's works,
>but that makes it messy when you link them in statically.
>
>You can also use gcc's __attribute__((constructor)) to tag a
>constructor function that's called at dlopen.  I'll make sure you
>can't double-register a hid, and we should be covered.

Yeah, in GPMI we solved this static vs dynamic linking using the above
ideas. When you compile a module in dynamic mode, a standard name is used
which is the same in all dynamic libs and is resolved using dlsym(); in
static mode the same function gets an unique name and becomes a
constructor. This can be easily done by using a macro wrapper to define
the init function in the module and make the framework (Makefile or
whatever in PCB's case) to use the right macro depending on static/dynamic
mode.

Igor2



_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev