05.12.2010 19:46, Wietse Venema wrote:
> Michael Tokarev:
>> The patch below is something I carry locally
>> since very long time, I forgot when I used it
>> first.  It were rejected when I first posted
>> it to postfix-users, but without it building
>> shared libpostfix is not possible due to
>> wrongly placed variable.  FWIW.
> 
> That is a very brief problem description. Can you explain it? 

The problem is that when you build postfix using shared
libpostfix (or components), only executables that actually
define var_command_maxtime can be linked (built), for all
others the link stage fails because pipe_command() uses
that variable but it's not defined in, say, postmap or
smtpd, so we end up with a missing symbol.

Exactly the same situation is with the var_scache_service
patch.

> What if var_command_maxtime is used for other forms of command
> execution than with pipe_command()? Isn't it wrong to make it a
> fixed attribute of the pipe_command module?

It is used only for pipe_command() so far.  It can be renamed
to var_pipe_command_maxtime to make it more explicit.

> Would not it be better to pass the var_command_maxtime value as an
> argument to the pipe_command() function?

That can be done as well.  For my patch I wanted to make it
as less intrusive as possible -- I didn't know I have to keep
it for 10 years, but it worked out well.

For a real fix, another argument for pipe_command() sounds
better.  I can make a patch for that against current code
if you prefer that.

Thanks!

/mjt

Reply via email to