Mac and regular expressions

[Martin Aspeli]

Poul-Henning Kamp wrote:
> In message <loom.20070705T135943-423 at post.gmane.org>, Martin Aspeli writes:
>> Hi,
>>
>> I think I'm being bitten by a bug related to Mac OS X (10.4) and regular
>> expressions.
> 
>> $ /usr/local/sbin/varnishd -a localhost:8080  -f /etc/varnish.conf 
>> Assert error in mgt_CallCc(), mgt_vcc.c line 214:
>>  Condition((dlclose(p)) == 0) not true.
>>  errno = 2 (No such file or directory)
>> Abort trap
> 
> Can you check the man pages for dlclose() on your mac, and see if they
> explain what it means when dlclose() fails this way ?

Yep - it doesn't look too useful, though. I'm guessing the question is, 
"which file is it that it can't find".

$ man dlclose

SYNOPSIS
      #include <dlfcn.h>

      int
      dlclose(void* handle);

DESCRIPTION
      dlclose() releases a reference to the dynamic library or bundle refer-
      enced by handle.  If the reference count drops to 0, the bundle is
      removed from the address space, and handle is rendered invalid.  Just
      before removing a dynamic library or bundle in this way, any 
termination
      routines in it are called.  handle is the value returned by a previous
      call to dlopen.

RETURN VALUES
      If dlclose() is successful, it returns a value of 0.  Otherwise it
      returns -1, and sets an error string that can be retrived with 
dlerror().

$ man dlerror

NAME
      dlerror -- get diagnostic information

SYNOPSIS
      #include <dlfcn.h>

      const char*
      dlerror(void);

DESCRIPTION
      dlerror() returns a null-terminated character string describing 
the last
      error that occurred on this thread during a call to dlopen(), 
dlsym(), or
      dlclose().  If no such error has occurred, dlerror() returns a null
      pointer.  At each call to dlerror(), the error indication is 
reset.  Thus
      in the case of two calls to dlerror(), where the second call 
follows the
      first immediately, the second call will always return a null pointer.

SEE ALSO
      dlopen(3) dlclose(3) dlsym(3) dyld(3)

...

Someone also suggested I invoke cc on /tmp/_.c, which gets:

$ cc /tmp/_.c

/usr/bin/ld: Undefined symbols:
_main
_VRT_GetHdr
_VRT_acl_fini
_VRT_acl_init
_VRT_acl_match
_VRT_alloc_backends
_VRT_count
_VRT_error
_VRT_fini_backend
_VRT_free_backends
_VRT_handling
_VRT_l_backend_host
_VRT_l_backend_port
_VRT_l_obj_ttl
_VRT_r_obj_cacheable
_VRT_r_obj_valid
_VRT_r_req_request
_VRT_set_backend_name

But I suspect that may be because I haven't passed the right parameters 
to cc.

Thanks,
Martin