uClinux may not have dhfcn.h et.al.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

uClinux may not have dhfcn.h et.al.

Andrew Cagney
Hi,

uClinux (which I'm treating as a linux variant) can be configured
without shared library support (no dl*() and no dlfcn.h).  The patch
below (hopefully attached):

- tweaks autoconf to define HAVE_DLFCN_H when "dlfcn.h" is present
(I've not otherwise changed that somewhat unusual logic)

- for linux, only enable DLL et.al. when "dlfcn.h" is present

- #ifdef'd code that used dlfcn.h and/or dl*() unconditionally

I've tried to be conservative here - a more aggressive version would
throw out much of the hard-wired unix dl* configuration and just rely
on autoconf.

Andrew

BTW, beyond a successful build, is there anything I should be looking
for when running "make" in pr/tests (on a native Linux system, say)?
_______________________________________________
dev-tech-nspr mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-nspr
Reply | Threaded
Open this post in threaded view
|

Re: uClinux may not have dhfcn.h et.al.

Wan-Teh Chang-3
On Fri, Dec 4, 2015 at 7:45 AM, Andrew Cagney <[hidden email]> wrote:
> Hi,
>
> uClinux (which I'm treating as a linux variant) can be configured
> without shared library support (no dl*() and no dlfcn.h).  The patch
> below (hopefully attached):

I didn't get the patch. I'm afraid that you'll need to paste it
inline, or better, file a bug report and attach the patch to it.

> BTW, beyond a successful build, is there anything I should be looking
> for when running "make" in pr/tests (on a native Linux system, say)?

You should run a few tests manually. I suggest the following:
    cvar -d
    cvar2
    perf

Then run the test harness (either runtests.sh or runtests.pl) to run
all tests. The Perl version is preferred (if your environment has
Perl) because it handles hung tests better.

Wan-Teh
_______________________________________________
dev-tech-nspr mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-nspr
Reply | Threaded
Open this post in threaded view
|

Re: uClinux may not have dhfcn.h et.al.

Andrew Cagney
On 4 December 2015 at 15:56, Wan-Teh Chang <[hidden email]> wrote:
> On Fri, Dec 4, 2015 at 7:45 AM, Andrew Cagney <[hidden email]> wrote:
>> Hi,
>>
>> uClinux (which I'm treating as a linux variant) can be configured
>> without shared library support (no dl*() and no dlfcn.h).  The patch
>> below (hopefully attached):
>
> I didn't get the patch. I'm afraid that you'll need to paste it
> inline, or better, file a bug report and attach the patch to it.

https://bugzilla.mozilla.org/show_bug.cgi?id=1231823

>> BTW, beyond a successful build, is there anything I should be looking
>> for when running "make" in pr/tests (on a native Linux system, say)?
>
> You should run a few tests manually. I suggest the following:

This is native linux:

>     cvar -d

$ ./cvar -d .
 cond var wait context switch- user/user:   7.00 usec
cond var wait context switch- user/kernel:  44.00 usec
cond var wait context switch- kernel/kernel:   4.00 usec
PASSED

>     cvar2

$ ./cvar2
...
PASS

>     perf

Didn't crash.

>
> Then run the test harness (either runtests.sh or runtests.pl) to run
> all tests. The Perl version is preferred (if your environment has
> Perl) because it handles hung tests better.
>
> Wan-Teh
_______________________________________________
dev-tech-nspr mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-nspr