Mailing List Archive

Martin Aspeli <optilude at gmx.net> writes:
> I think I'm being bitten by a bug related to Mac OS X (10.4) and regular
> expressions.

Looks like MacOS's libc lacks the POSIX regexp API. Unfortunately,
until we manage to get hold of a MacOS box to test on, there isn't much
we can do to fix the build.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Buy a Mac Mini? :)

I can help you test if you can give me instructions. My C skills are
perhaps a bit rusty, but I can definitely make it build and try out
things.

Just from a quick Google,
http://developer.apple.com/documentation/Darwin/Reference/Manpages/man3/regex.3.html
seems to suggest that it does have POSIX regex.

Martin

On 7/5/07, Dag-Erling Sm?rgrav <des at linpro.no> wrote:
> Martin Aspeli <optilude at gmx.net> writes:
> > I think I'm being bitten by a bug related to Mac OS X (10.4) and regular
> > expressions.
>
> Looks like MacOS's libc lacks the POSIX regexp API. Unfortunately,
> until we manage to get hold of a MacOS box to test on, there isn't much
> we can do to fix the build.
>
> DES
> --
> Dag-Erling Sm?rgrav
> Senior Software Developer
> Linpro AS - www.linpro.no
>
>

"Martin Aspeli" <optilude at gmx.net> writes:
> Buy a Mac Mini? :)

Sure, what's your credit card number again? :)

> I can help you test if you can give me instructions.

I don't want code in the repo that I can't test myself, or at least
build.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Hi Dag

On 7/5/07, Dag-Erling Sm?rgrav <des at linpro.no> wrote:
> "Martin Aspeli" <optilude at gmx.net> writes:
> > Buy a Mac Mini? :)
>
> Sure, what's your credit card number again? :)

Find a customer with one, that's what I normally do. :)

> > I can help you test if you can give me instructions.
>
> I don't want code in the repo that I can't test myself, or at least
> build.

Neither do I, but we're basing this on an assumption (which may or may
not be correct) about the OS X regex implementation. If you can
identify any points in the code where I could apply some hypothetical
patch/change or add debug info that may at least help prove or
disprove that theory. It may well be that this is an issue that
affects other platforms as well.

Martin

"Martin Aspeli" <optilude at gmx.net> writes:
> Dag-Erling Sm?rgrav <des at linpro.no> writes:
> > I don't want code in the repo that I can't test myself, or at least
> > build.
> Neither do I, but we're basing this on an assumption (which may or may
> not be correct) about the OS X regex implementation. If you can
> identify any points in the code where I could apply some hypothetical
> patch/change or add debug info that may at least help prove or
> disprove that theory. It may well be that this is an issue that
> affects other platforms as well.

There are other issues as well. Varnish likely runs the compiler with
the wrong flags (why on earth couldn't Apple keep gcc's command-line
syntax when they adopted it as their system compiler?), and for some
reason configure doesn't correctly detect the absence of strndup() and
enable the compat implementation. Not to mention the clock_gettime()
issue, which will surely come back to bite us at some point...

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

> > Neither do I, but we're basing this on an assumption (which may or may
> > not be correct) about the OS X regex implementation. If you can
> > identify any points in the code where I could apply some hypothetical
> > patch/change or add debug info that may at least help prove or
> > disprove that theory. It may well be that this is an issue that
> > affects other platforms as well.
>
> There are other issues as well. Varnish likely runs the compiler with
> the wrong flags (why on earth couldn't Apple keep gcc's command-line
> syntax when they adopted it as their system compiler?), and for some
> reason configure doesn't correctly detect the absence of strndup() and
> enable the compat implementation. Not to mention the clock_gettime()
> issue, which will surely come back to bite us at some point...

That's a shame. So what we're saying is that Varnish at this point
doesn't really support Mac OS X, and won't unless someone donates a
Mac to the core developers?

Perhaps we could start some kind of pledge? The Plone community
basically bought the developer of poEdit a Mac via fundable.org so
that he'd port poEdit to OS X. There's a lot of interest in Varnish
from the Plone community (since Squid scares me senseless), and a lot
of Plone developers use Macs, so we may be able to achieve something
similar if there's a commitment from the core Varnish developers to
support OS X in return for a Mac.

Martin

"Martin Aspeli" <optilude at gmx.net> writes:
> That's a shame. So what we're saying is that Varnish at this point
> doesn't really support Mac OS X

correct

> and won't unless someone donates a Mac to the core developers?

I'd rather say "until the core developers get their hands on a Mac",
which may happen in a variety of ways. Linpro is an Apple partner, so
we may be able to get a good price.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

Dag-Erling Sm?rgrav <des at linpro.no> writes:
> I'd rather say "until the core developers get their hands on a Mac",
> which may happen in a variety of ways. Linpro is an Apple partner, so
> we may be able to get a good price.

(of course, I'd prefer an XServe or some other 64-bit model, but they
cost real money...)

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

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 ?

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Arn?r Kristj?nsson <addi at addihetja.com> writes:
> Would remote root access to a Mac OS X Server box help?

It would help in the short run; I could at least make sure 1.1 runs on
MacOS X.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

>> and won't unless someone donates a Mac to the core developers?
> I'd rather say "until the core developers get their hands on a Mac",
> which may happen in a variety of ways. Linpro is an Apple partner,
> so we may be able to get a good price.

Would remote root access to a Mac OS X Server box help?

A.
>> and won't unless someone donates a Mac to the core developers?
> I'd rather say "until the core developers get their hands on a Mac",
> which may happen in a variety of ways. Linpro is an Apple partner,
> so we may be able to get a good price.

Would remote root access to a Mac OS X Server box help?

A.