Circular symlink created when only SHLIB_MAJOR is defined

Hi list,

(Please Cc: in your reply, I'm not subscribed.)

I've already sent this e-mail to tech-toolchain but got
no answer.
I dare to resend it here to reach a larger audience.

bsd.lib.mk supports multiple levels of precision for shared
libraries
version numbering as the following code snippet shows:

% .if defined(SHLIB_MAJOR) && !empty(SHLIB_MAJOR)   
                     # {
% .if defined(SHLIB_MINOR) && !empty(SHLIB_MINOR)
% .if defined(SHLIB_TEENY) && !empty(SHLIB_TEENY)
%
SHLIB_FULLVERSION=$.$.${SHLIB_TEEN
Y}
% .else
% SHLIB_FULLVERSION=$.$
% .endif
% .else
% SHLIB_FULLVERSION=$
% .endif
% .endif                                                    
             # }

The problem I've been faced occurs in the later case when
you only
define SHLIB_MAJOR.  Here is what happens during the linkage
of my
shared library:

% #     build  poolexecutor/libzthreadstub.so.1
% rm -f libzthreadstub.so.1
% cc -Wl,-x -shared -Wl,-soname,libzthreadstub.so.1   -o
libzthreadstub.so.1   -Wl,-rpath-link,/lib:/usr/lib  -L/lib 
-Wl,--whole-archive libzthreadstub_pic.a
-Wl,--no-whole-archive -lpthread
% ln -sf libzthreadstub.so.1 libzthreadstub.so.1.tmp
% mv -f libzthreadstub.so.1.tmp libzthreadstub.so.1
% ln -sf libzthreadstub.so.1 libzthreadstub.so.tmp
% mv -f libzthreadstub.so.tmp libzthreadstub.so

This results in a circular symlink for libzthreadstub.so.1:

% octobrebsd:poolexecutor$ stat -f "%N -> %Y"
libzthreadstub.so.1
% libzthreadstub.so.1 -> libzthreadstub.so.1


According to the CVS repository, this ln(1)/mv(1) dance is
used to
prevent small races during parallel builds where libc.so
could no
longer exist for a small time (see rev. 1.177).  The
proposed fix
is attached.

This works for me, at least.
Best regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot
org >

On Sun, Jan 28, 2007 at 06:45:48AM -0500, Thor Lancelot
Simon wrote:
> On Sun, Jan 28, 2007 at 06:59:04AM +0100, Jeremie Le
Hen wrote:
> > Hi list,
> > 
> > (Please Cc: in your reply, I'm not subscribed.)
> > 
> > I've already sent this e-mail to
tech-toolchain but got no answer.
> > I dare to resend it here to reach a larger
audience.
> 
> The audience dares to point out that a shared library
with only a major
> number is not supported.
> 
> "Unix gives you enough rope..."

Ok, I'm sorry.  Is it possible to trigger an error whenever
only the
major version if defined ?  NetBSD's make(1) does not have
the .error
statement, what can I use instead ?

Thank you.
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot
org >