Mailing List Archive

Varnish on OS X and bug #118
Hi guys,

With Varnish 1.1, I'm able to get it to run on OS X after manually
applying the patch in http://varnish.projects.linpro.no/ticket/118. Yay!

The funny thing is that someone else with the same version of OS X does
*not* seem to have to apply the patch.

I've tried to use the most recent libtool from MacPorts, but to no avail.

Two questions:

- Is there some workaround I can do to make this work without having
to patch the source?

- Is there some way Varnish's configure script could detect OS X and
make this change as appropriate?

I can't work out what export_dynamic_flag_spec="-flat_namespace"
actually *does, making it hard to explore the space.

Why do I care so much? I want to build varnish automatically as part of
a server config, using zc.buildout and
http://cheeseshop.python.org/pypi/plone.recipe.varnish. We could try to
patch in that recipe, but I'd rather not.

Cheers,
Martin

--
Acquisition is a jealous mistress
Varnish on OS X and bug #118 [ In reply to ]
Martin Aspeli <optilude at gmx.net> writes:
> Two questions:
>
> - Is there some workaround I can do to make this work without having
> to patch the source?
>
> - Is there some way Varnish's configure script could detect OS X and
> make this change as appropriate?
>
> I can't work out what export_dynamic_flag_spec="-flat_namespace"
> actually *does, making it hard to explore the space.

We link varnishd with -export-dynamic, which tells libtool that
symbols defined in varnishd should be available to libraries linked
with varnishd. Otherwise, varnishd would be able to call VCL code but
the VCL code would not be able to call the VCL runtime (VRT_*) which
is contained partly in varnishd and partly in libvarnish.

The export_dynamic_flag_spec variable tells libtool how it should
translate -export-dynamic when invoking the native linker. On systems
using the GNU toolchain, this is simply ld's --export-dynamic option
(or gcc's -Wl,--export-dynamic which tells it to invoke ld with the
--export-dynamic option). On MacOS X, this is -flat_namespace, which
tells the linker to use a single namespace for program and libraries
instead of a two-level namespace where the program can look up symbols
in the libraries but not the other way around. Note than until 10.3,
-flat_namespace used to be the default.

There is another option you might try instead of the libtool hack,
although I haven't tested it so I don't know if it will actually work:

Index: bin/varnishd/mgt_vcc.c
===================================================================
--- bin/varnishd/mgt_vcc.c (revision 1808)
+++ bin/varnishd/mgt_vcc.c (working copy)
@@ -182,7 +182,7 @@
len = snprintf(buf, sizeof buf,
"ln -f %s _.c ;" /* XXX: for debugging */
#ifdef __APPLE__
- "exec cc -dynamiclib -Wl,-flat_namespace,-undefined,suppress -o %s -x c - < %s 2>&1",
+ "exec cc -dynamiclib -Wl,-undefined,dynamic_lookup -o %s -x c - < %s 2>&1",
#else
"exec cc -fpic -shared -Wl,-x -o %s -x c - < %s 2>&1",
#endif

The downside is that this will not work at all on pre-10.3 systems,
whereas -flat_namespace is simply a nop on pre-10.3.

Let me know how it works out...

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no
Varnish on OS X and bug #118 [ In reply to ]
Hi Dag,

Thanks for a detailed reply!

The problem, I suppose, is that your other solution still involves
patching the sources.

I do wonder why my MacPorts-installed libtool didn't work, though.
This ought to be the same as the GNU version. It installs as
'glibtool', but I symlinked to libtool and made sure /opt/local/bin
(where it gets installed) comes first.

Ah well, at least I understand why now.

Cheers,
Martin

On 8/7/07, Dag-Erling Sm?rgrav <des at linpro.no> wrote:
> Martin Aspeli <optilude at gmx.net> writes:
> > Two questions:
> >
> > - Is there some workaround I can do to make this work without having
> > to patch the source?
> >
> > - Is there some way Varnish's configure script could detect OS X and
> > make this change as appropriate?
> >
> > I can't work out what export_dynamic_flag_spec="-flat_namespace"
> > actually *does, making it hard to explore the space.
>
> We link varnishd with -export-dynamic, which tells libtool that
> symbols defined in varnishd should be available to libraries linked
> with varnishd. Otherwise, varnishd would be able to call VCL code but
> the VCL code would not be able to call the VCL runtime (VRT_*) which
> is contained partly in varnishd and partly in libvarnish.
>
> The export_dynamic_flag_spec variable tells libtool how it should
> translate -export-dynamic when invoking the native linker. On systems
> using the GNU toolchain, this is simply ld's --export-dynamic option
> (or gcc's -Wl,--export-dynamic which tells it to invoke ld with the
> --export-dynamic option). On MacOS X, this is -flat_namespace, which
> tells the linker to use a single namespace for program and libraries
> instead of a two-level namespace where the program can look up symbols
> in the libraries but not the other way around. Note than until 10.3,
> -flat_namespace used to be the default.
>
> There is another option you might try instead of the libtool hack,
> although I haven't tested it so I don't know if it will actually work:
>
> Index: bin/varnishd/mgt_vcc.c
> ===================================================================
> --- bin/varnishd/mgt_vcc.c (revision 1808)
> +++ bin/varnishd/mgt_vcc.c (working copy)
> @@ -182,7 +182,7 @@
> len = snprintf(buf, sizeof buf,
> "ln -f %s _.c ;" /* XXX: for debugging */
> #ifdef __APPLE__
> - "exec cc -dynamiclib -Wl,-flat_namespace,-undefined,suppress -o %s -x c - < %s 2>&1",
> + "exec cc -dynamiclib -Wl,-undefined,dynamic_lookup -o %s -x c - < %s 2>&1",
> #else
> "exec cc -fpic -shared -Wl,-x -o %s -x c - < %s 2>&1",
> #endif
>
> The downside is that this will not work at all on pre-10.3 systems,
> whereas -flat_namespace is simply a nop on pre-10.3.
>
> Let me know how it works out...
>
> DES
> --
> Dag-Erling Sm?rgrav
> Senior Software Developer
> Linpro AS - www.linpro.no
>
>
Varnish on OS X and bug #118 [ In reply to ]
"Martin Aspeli" <optilude at gmx.net> writes:
> The problem, I suppose, is that your other solution still involves
> patching the sources.

Yes, but if this solution works, I'll apply it in Subversion and it
will be in 1.1.1.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no
Varnish on OS X and bug #118 [ In reply to ]
Ah, I get you! Right, I'll try it tonight when I get home. Thanks! :)

Martin

On 8/7/07, Dag-Erling Sm?rgrav <des at linpro.no> wrote:
> "Martin Aspeli" <optilude at gmx.net> writes:
> > The problem, I suppose, is that your other solution still involves
> > patching the sources.
>
> Yes, but if this solution works, I'll apply it in Subversion and it
> will be in 1.1.1.
>
> DES
> --
> Dag-Erling Sm?rgrav
> Senior Software Developer
> Linpro AS - www.linpro.no
>
>
Varnish on OS X and bug #118 [ In reply to ]
Martin Aspeli wrote:
> Ah, I get you! Right, I'll try it tonight when I get home. Thanks! :)
>
> Martin
>
> On 8/7/07, Dag-Erling Sm?rgrav <des at linpro.no> wrote:
>> "Martin Aspeli" <optilude at gmx.net> writes:
>>> The problem, I suppose, is that your other solution still involves
>>> patching the sources.
>> Yes, but if this solution works, I'll apply it in Subversion and it
>> will be in 1.1.1.

Alas, I have the exact same problem after making the change you suggested.

In bin/varnishd/mgt_vcc.c, I have:

#ifdef __APPLE__
"exec cc -dynamiclib -Wl,-undefined,dynamic_lookup -o %s -x c - <
%s 2>&1",
#else
"exec cc -fpic -shared -Wl,-x -o %s -x c - < %s 2>&1",
#endif

Oh well :)

Martin

--
Acquisition is a jealous mistress