Symbol versioning - Samba

This is a discussion on Symbol versioning - Samba ; Hi, I just checked in support for symbol versioning to v3-2-stable to see how the build farm likes it. For now I only added it for libtalloc, libtdb and libwbclient, the aim of this is to extent the api later ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 23

Thread: Symbol versioning

  1. Symbol versioning

    Hi,

    I just checked in support for symbol versioning to v3-2-stable
    to see how the build farm likes it.

    For now I only added it for libtalloc, libtdb and libwbclient,
    the aim of this is to extent the api later without breaking
    already compiled binaries. For details have a look at
    http://people.redhat.com/~drepper/symbol-versioning.

    In case the build-farm likes it
    I think we can add it also for bin/libnetapi.so as this is also a new
    library.

    But we should also add it to
    bin/libsmbclient.so
    bin/libsmbsharemodes.so
    bin/libaddns.so
    if the implementation isn't compatible to 3.0.29.

    Comments please, I'd like to have that in 3.2.0:-)

    metze



    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFINYvAm70gjA5TCD8RAkxkAJ9PrrHgmBtuJWyozOOuCo WcOPvI5gCdExKo
    9ZE73y+xGcfJC/X3+qPdoNs=
    =pT/z
    -----END PGP SIGNATURE-----


  2. Re: Symbol versioning

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Stefan (metze) Metzmacher wrote:
    > Hi,
    >
    > I just checked in support for symbol versioning to v3-2-stable
    > to see how the build farm likes it.
    >
    > For now I only added it for libtalloc, libtdb and libwbclient,
    > the aim of this is to extent the api later without breaking
    > already compiled binaries. For details have a look at
    > http://people.redhat.com/~drepper/symbol-versioning.


    So how does this help us on non-linxu platforms that use the
    native ld? This doesn't seem to help with API version unless it
    is portable everywhere.




    jerry
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFINZMJIR7qMdg1EfYRAgwSAJ9TsM7qOO87RP7j5kIzW/0+Gfqc8QCeOTd3
    cJk9Xu2sb9aQvkIZRcIzm8s=
    =bLdz
    -----END PGP SIGNATURE-----


  3. Re: Symbol versioning

    Gerald (Jerry) Carter schrieb:
    > Stefan (metze) Metzmacher wrote:
    >> Hi,

    >
    >> I just checked in support for symbol versioning to v3-2-stable
    >> to see how the build farm likes it.

    >
    >> For now I only added it for libtalloc, libtdb and libwbclient,
    >> the aim of this is to extent the api later without breaking
    >> already compiled binaries. For details have a look at
    >> http://people.redhat.com/~drepper/symbol-versioning.

    >
    > So how does this help us on non-linxu platforms that use the
    > native ld? This doesn't seem to help with API version unless it
    > is portable everywhere.


    It doesn't help everywhere, but it doesn't harm where it's supported.
    So far the build-farm looks ok.

    metze


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFINZbhm70gjA5TCD8RAvbeAJ4vLq5hPc+y7biFgVwyKC M5CLGNOgCgmypK
    w0ziX8mTMCF7f4kmVcu8wBg=
    =ME03
    -----END PGP SIGNATURE-----


  4. Re: Symbol versioning

    Stefan (metze) Metzmacher wrote:
    >
    > I just checked in support for symbol versioning to v3-2-stable
    > to see how the build farm likes it.


    v3-2-test ...


    --
    Michael Adam
    SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
    phone: +49-551-370000-0, fax: +49-551-370000-9
    AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
    http://www.SerNet.DE, mailto: Info @ SerNet.DE

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)
    Comment: comment

    iD8DBQFINZi9yU9JOBhPkDQRAgeyAJ9Tk2mz+CWJuLnFNcofOa HsttJLKwCfcMrF
    dVWmk1bQQe/6Iqv1ZVfloAc=
    =7ak1
    -----END PGP SIGNATURE-----


  5. Re: Symbol versioning

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Stefan (metze) Metzmacher wrote:
    > Gerald (Jerry) Carter schrieb:
    >> Stefan (metze) Metzmacher wrote:
    >>> Hi,
    >>> I just checked in support for symbol versioning to v3-2-stable
    >>> to see how the build farm likes it.
    >>> For now I only added it for libtalloc, libtdb and libwbclient,
    >>> the aim of this is to extent the api later without breaking
    >>> already compiled binaries. For details have a look at
    >>> http://people.redhat.com/~drepper/symbol-versioning.

    >> So how does this help us on non-linxu platforms that use the
    >> native ld? This doesn't seem to help with API version unless it
    >> is portable everywhere.

    >
    > It doesn't help everywhere, but it doesn't harm where it's supported.
    > So far the build-farm looks ok.


    But it doesn't help us with versioning on platforms that
    don't use GNU ld right? So we have to go through all the hoops
    of maintaining backwards compatibility (compatible DSO files).
    So what I'm missing is that this seems to make those platforms
    the corner cases which means they are guaranteed to break.
    My have to support two solutions at all ?

    What amI missing here?


    cheers, jerry
    - --
    ================================================== ===================
    Samba ------- http://www.samba.org
    Likewise Software --------- http://www.likewisesoftware.com
    "What man is a man who does not make the world better?" --Balian
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFINZp+IR7qMdg1EfYRAhqSAJ93BQMzryhALuPOqCW+e4 Xg7nRnegCgpud8
    E0MuBavD49g9YtOMp766dPI=
    =pyrB
    -----END PGP SIGNATURE-----


  6. Questions re Symbol versioning

    Stefan (metze) Metzmacher wrote:
    >>It doesn't help everywhere, but it doesn't harm where it's supported.
    >>So far the build-farm looks ok.


    Gerald (Jerry) Carter schrieb:
    > But it doesn't help us with versioning on platforms that
    > don't use GNU ld right? So we have to go through all the hoops
    > of maintaining backwards compatibility (compatible DSO files).
    > So what I'm missing is that this seems to make those platforms
    > the corner cases which means they are guaranteed to break.
    > My have to support two solutions at all ?


    A logical next question is how does it fail when the linker
    doesn't honor the versioning? Doe you get
    - the first one found in the file?
    - the last one?
    - both if it's called more than once?

    Another might be, can you implement it with, for example,
    name mangling for linkers which don't support it?

    --dave
    --
    David Collier-Brown, | Always do right. This will gratify
    System Programmer and Author | some people and astonish the rest
    davecb@spamcop.net | -- Mark Twain
    (416) 223-5943


  7. Re: Questions re Symbol versioning

    Stefan (metze) Metzmacher wrote:
    >
    >>> It doesn't help everywhere, but it doesn't harm where it's supported.
    >>> So far the build-farm looks ok.

    >
    >
    > Gerald (Jerry) Carter schrieb:
    >
    >> But it doesn't help us with versioning on platforms that
    >> don't use GNU ld right? So we have to go through all the hoops
    >> of maintaining backwards compatibility (compatible DSO files).
    >> So what I'm missing is that this seems to make those platforms
    >> the corner cases which means they are guaranteed to break.
    >> My have to support two solutions at all ?

    >
    >
    > A logical next question is how does it fail when the linker
    > doesn't honor the versioning? Doe you get
    > - the first one found in the file?
    > - the last one?
    > - both if it's called more than once?
    >
    > Another might be, can you implement it with, for example,
    > name mangling for linkers which don't support it?



    D'oh! I forgot the most basic question: what are the interfaces
    you're planning to change? Several forms of mutation can be
    done cleanly without signature changes...

    --dave (getting stupid in his old age) c-b


    --
    David Collier-Brown | Always do right. This will gratify
    Sun Microsystems, Toronto | some people and astonish the rest
    davecb@sun.com | -- Mark Twain
    (905) 943-1983, cell: (647) 833-9377, (800) 555-9786 x56583
    bridge: (877) 385-4099 code: 506 9191#


  8. Re: Questions re Symbol versioning

    David Collier-Brown schrieb:
    > Stefan (metze) Metzmacher wrote:
    >>
    >>>> It doesn't help everywhere, but it doesn't harm where it's supported.
    >>>> So far the build-farm looks ok.

    >>
    >>
    >> Gerald (Jerry) Carter schrieb:
    >>
    >>> But it doesn't help us with versioning on platforms that
    >>> don't use GNU ld right? So we have to go through all the hoops
    >>> of maintaining backwards compatibility (compatible DSO files).
    >>> So what I'm missing is that this seems to make those platforms
    >>> the corner cases which means they are guaranteed to break.
    >>> My have to support two solutions at all ?

    >>
    >>
    >> A logical next question is how does it fail when the linker
    >> doesn't honor the versioning? Doe you get
    >> - the first one found in the file?
    >> - the last one?
    >> - both if it's called more than once?
    >>
    >> Another might be, can you implement it with, for example,
    >> name mangling for linkers which don't support it?

    >
    >
    > D'oh! I forgot the most basic question: what are the interfaces
    > you're planning to change? Several forms of mutation can be
    > done cleanly without signature changes...


    We don't want to change a functions yet, but we want to add new
    functions to the interface which older versions of the library won't have.

    metze


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFINl08m70gjA5TCD8RAtRVAKCdBAHvUtzV2DBEpL1Pmf 2wg2rPVwCgictH
    BZLd3FGeJvifnEDa9n+FoQs=
    =TEs/
    -----END PGP SIGNATURE-----


  9. Re: Symbol versioning

    Gerald (Jerry) Carter schrieb:
    > Stefan (metze) Metzmacher wrote:
    >> Gerald (Jerry) Carter schrieb:
    >>> Stefan (metze) Metzmacher wrote:
    >>>> Hi,
    >>>> I just checked in support for symbol versioning to v3-2-stable
    >>>> to see how the build farm likes it.
    >>>> For now I only added it for libtalloc, libtdb and libwbclient,
    >>>> the aim of this is to extent the api later without breaking
    >>>> already compiled binaries. For details have a look at
    >>>> http://people.redhat.com/~drepper/symbol-versioning.
    >>> So how does this help us on non-linxu platforms that use the
    >>> native ld? This doesn't seem to help with API version unless it
    >>> is portable everywhere.

    >> It doesn't help everywhere, but it doesn't harm where it's supported.
    >> So far the build-farm looks ok.

    >
    > But it doesn't help us with versioning on platforms that
    > don't use GNU ld right? So we have to go through all the hoops
    > of maintaining backwards compatibility (compatible DSO files).
    > So what I'm missing is that this seems to make those platforms
    > the corner cases which means they are guaranteed to break.
    > My have to support two solutions at all ?
    >
    > What amI missing here?


    Ok, we'll not use symbol versioning and then take care
    of maintaining backward and forward compatibility...
    Do you have plans how to do that?

    Note that we also need forward compat to use a new smbd with
    an old winbind, symbol versioning would have worked arround that
    as only new function would have a new version number...

    metze


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFINm9vm70gjA5TCD8RAtg6AKCWxjCcRIpCnDPgpzcAut nVQ0dPUgCePNrW
    GgmE5gbE4lP3eKxRhvTbaqA=
    =jxwI
    -----END PGP SIGNATURE-----


  10. Re: Symbol versioning

    Stefan (metze) Metzmacher schrieb:
    > Gerald (Jerry) Carter schrieb:
    >> Stefan (metze) Metzmacher wrote:
    >>> Gerald (Jerry) Carter schrieb:
    >>>> Stefan (metze) Metzmacher wrote:
    >>>>> Hi,
    >>>>> I just checked in support for symbol versioning to v3-2-stable
    >>>>> to see how the build farm likes it.
    >>>>> For now I only added it for libtalloc, libtdb and libwbclient,
    >>>>> the aim of this is to extent the api later without breaking
    >>>>> already compiled binaries. For details have a look at
    >>>>> http://people.redhat.com/~drepper/symbol-versioning.
    >>>> So how does this help us on non-linxu platforms that use the
    >>>> native ld? This doesn't seem to help with API version unless it
    >>>> is portable everywhere.
    >>> It doesn't help everywhere, but it doesn't harm where it's supported.
    >>> So far the build-farm looks ok.

    >> But it doesn't help us with versioning on platforms that
    >> don't use GNU ld right? So we have to go through all the hoops
    >> of maintaining backwards compatibility (compatible DSO files).
    >> So what I'm missing is that this seems to make those platforms
    >> the corner cases which means they are guaranteed to break.
    >> My have to support two solutions at all ?
    >>
    >> What amI missing here?

    >
    > Ok, we'll not use symbol versioning and then take care
    > of maintaining backward and forward compatibility...
    > Do you have plans how to do that?
    >
    > Note that we also need forward compat to use a new smbd with
    > an old winbind, symbol versioning would have worked arround that
    > as only new function would have a new version number...


    I discussed that again with Volker, Karolin and Michael
    again and added it, but I also added a --enable-symbol-versioning
    which defaults to yes if gnu ld is used.

    We can still use a different way and update the library version
    and have compat libraries to handle updates

    metze


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFINrtLm70gjA5TCD8RAuWTAJ4mX3lqePlKTlg7qdIiNj hrG+GxkwCfQOsJ
    6FbXK55QiJwEuILHTUJldJs=
    =XLwh
    -----END PGP SIGNATURE-----


  11. Re: Symbol versioning

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Stefan (metze) Metzmacher wrote:

    > Ok, we'll not use symbol versioning and then take care
    > of maintaining backward and forward compatibility...
    > Do you have plans how to do that?


    yes. I already explained that in a previous mail. You simply
    have a compat library that proivides the old API but internally
    uses the new functions.

    > Note that we also need forward compat to use a new smbd with
    > an old winbind, symbol versioning would have worked arround that
    > as only new function would have a new version number...


    Not really. Until (if) we allow winbindd to be on a separate
    release cycle, this is not an issue.






    cheers, jerry
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFINxPiIR7qMdg1EfYRArjdAJwJ+hI2iajQ/D14T9I8MgcJvvoyygCfVipS
    dH8ncsRtf10E0kwVdp0KBdw=
    =JGwB
    -----END PGP SIGNATURE-----


  12. Re: Symbol versioning

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Stefan (metze) Metzmacher wrote:

    > I discussed that again with Volker, Karolin and Michael
    > again and added it, but I also added a --enable-symbol-versioning
    > which defaults to yes if gnu ld is used.


    Metze, these off list discussion to decide things are not good.
    No offense. I know you all work together in the same office, but....

    > We can still use a different way and update the library version
    > and have compat libraries to handle updates


    So now we have two different mechanisms to maintain. Wonderful.




    cheers, jerry
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFINxQ4IR7qMdg1EfYRAn37AKCMegp8iIlzRFi/boi32aTqeodwbgCfQIkj
    6h1VniwHvfepofq8qyS9pEs=
    =HJIL
    -----END PGP SIGNATURE-----


  13. Re: Symbol versioning

    Jerry, Metze,

    On Fri, May 23, 2008 at 02:00:08PM -0500, Gerald (Jerry) Carter wrote:
    > Metze, these off list discussion to decide things are not good.
    > No offense. I know you all work together in the same office, but....


    Of course you are right!
    It was due to the release day (/me did not want to defer it).
    Introducing that feature with 3.2.1 or 3.3.0 doesn't make sense...

    The discussion should have taken place earlier.

    > So now we have two different mechanisms to maintain. Wonderful.


    Metze, maybe you can write your arguments down in detail and send them
    to the list again?

    Karolin

    --
    SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
    phone: +49-551-370000-0, fax: +49-551-370000-9
    AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
    http://www.SerNet.DE, mailto: Info @ SerNet.DE


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.4-svn0 (GNU/Linux)

    iD8DBQFIOmxFKGi9fisXk1ERAuYBAJ9phEbjbKQ1s4NWPN9gih 43WwO71QCggcyM
    cZ9tWqmdTScVX8KfmDKp5yo=
    =y3eB
    -----END PGP SIGNATURE-----


  14. Re: Questions re Symbol versioning

    Then that's one of the easy cases: think of it as a relational database (;-))
    where you ca add columns to the end, but to get rid of a column you
    need to have all it's elements NULL (ie, all callers can accept a NULL
    return code) and to change one you need to add and then delete.

    --dave

    Stefan (metze) Metzmacher wrote:
    > David Collier-Brown schrieb:
    >
    >>Stefan (metze) Metzmacher wrote:
    >>
    >>>>>It doesn't help everywhere, but it doesn't harm where it's supported.
    >>>>>So far the build-farm looks ok.
    >>>
    >>>
    >>>Gerald (Jerry) Carter schrieb:
    >>>
    >>>
    >>>>But it doesn't help us with versioning on platforms that
    >>>>don't use GNU ld right? So we have to go through all the hoops
    >>>>of maintaining backwards compatibility (compatible DSO files).
    >>>>So what I'm missing is that this seems to make those platforms
    >>>>the corner cases which means they are guaranteed to break.
    >>>>My have to support two solutions at all ?
    >>>
    >>>
    >>>A logical next question is how does it fail when the linker
    >>>doesn't honor the versioning? Doe you get
    >>>- the first one found in the file?
    >>>- the last one?
    >>>- both if it's called more than once?
    >>>
    >>>Another might be, can you implement it with, for example,
    >>>name mangling for linkers which don't support it?

    >>
    >>
    >> D'oh! I forgot the most basic question: what are the interfaces
    >>you're planning to change? Several forms of mutation can be
    >>done cleanly without signature changes...

    >
    >
    > We don't want to change a functions yet, but we want to add new
    > functions to the interface which older versions of the library won't have.
    >
    > metze
    >


    --
    David Collier-Brown | Always do right. This will gratify
    Sun Microsystems, Toronto | some people and astonish the rest
    davecb@sun.com | -- Mark Twain
    (905) 943-1983, cell: (647) 833-9377, (800) 555-9786 x56583
    bridge: (877) 385-4099 code: 506 9191#


  15. Re: Symbol versioning

    Hi Jerry,

    >> I discussed that again with Volker, Karolin and Michael
    >> again and added it, but I also added a --enable-symbol-versioning
    >> which defaults to yes if gnu ld is used.

    >
    > Metze, these off list discussion to decide things are not good.
    > No offense. I know you all work together in the same office, but....


    Yes, you're absolutely right.

    >> We can still use a different way and update the library version
    >> and have compat libraries to handle updates

    >
    > So now we have two different mechanisms to maintain. Wonderful.


    The things I would like to have are these:

    - Make it possible to use an old smbd with a newer winbindd
    - Make it possible to use a new smbd against an older winbindd

    Using symbol versioning makes that easy, as the binary always
    links against the same library soname. So a new smbd would still
    load with an old libwbclient, because the soname of the new library
    is the same and smbd only uses functions of the old interface
    and has references to the old versioned symbols only.
    Other tools like wbinfo would not be able to load with an old
    library as it will also have references to new functions.

    But as we've currently symbol versioning only when using gnu ld
    it's not available on every platform we support.

    We could also work with compat libraries (as you proposed, but)
    in both directions, one compat library that provides the old interfaces
    against a new library and also a library that provides the new interface
    against an old library implementing the new functions as stubs
    returning WBC_ERR_NOT_IMPLEMENTED.

    I'm currently doing some testing with compat libraries and
    they may have also some portability problems, I'll continue
    some testing tomorrow and will come back with the results then.

    If the compat libraries support all we need, we can think about
    removing symbol versioning and create a rc2 release...ok?

    metze


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFIOtLmm70gjA5TCD8RApaBAKCKy/IxKKDut8P0omLe7S3qcQ0i2gCgvXaM
    UauoVhgU+DapERHzxZgLWSI=
    =3/Ei
    -----END PGP SIGNATURE-----


  16. Re: Symbol versioning

    On Mon, 2008-05-26 at 17:10 +0200, Stefan (metze) Metzmacher wrote:
    > Hi Jerry,
    >
    > >> I discussed that again with Volker, Karolin and Michael
    > >> again and added it, but I also added a --enable-symbol-versioning
    > >> which defaults to yes if gnu ld is used.

    > >
    > > Metze, these off list discussion to decide things are not good.
    > > No offense. I know you all work together in the same office, but....

    >
    > Yes, you're absolutely right.
    >
    > >> We can still use a different way and update the library version
    > >> and have compat libraries to handle updates

    > >
    > > So now we have two different mechanisms to maintain. Wonderful.

    >
    > The things I would like to have are these:
    >
    > - Make it possible to use an old smbd with a newer winbindd
    > - Make it possible to use a new smbd against an older winbindd
    >
    > Using symbol versioning makes that easy, as the binary always
    > links against the same library soname. So a new smbd would still
    > load with an old libwbclient, because the soname of the new library
    > is the same and smbd only uses functions of the old interface
    > and has references to the old versioned symbols only.
    > Other tools like wbinfo would not be able to load with an old
    > library as it will also have references to new functions.
    >
    > But as we've currently symbol versioning only when using gnu ld
    > it's not available on every platform we support.
    >
    > We could also work with compat libraries (as you proposed, but)
    > in both directions, one compat library that provides the old interfaces
    > against a new library and also a library that provides the new interface
    > against an old library implementing the new functions as stubs
    > returning WBC_ERR_NOT_IMPLEMENTED.
    >
    > I'm currently doing some testing with compat libraries and
    > they may have also some portability problems, I'll continue
    > some testing tomorrow and will come back with the results then.
    >
    > If the compat libraries support all we need, we can think about
    > removing symbol versioning and create a rc2 release...ok?


    To be honest, from a distribution PoV i'd rather much prefer keeping
    symbol versioning.

    Although I do not have any problem updating all the components at the
    same time it usually makes for a better experience.

    Simo.

    --
    Simo Sorce
    Samba Team GPL Compliance Officer
    Senior Software Engineer at Red Hat Inc.


  17. Re: Symbol versioning

    simo wrote:
    > On Mon, 2008-05-26 at 17:10 +0200, Stefan (metze) Metzmacher wrote:
    >>The things I would like to have are these:
    >>
    >>- Make it possible to use an old smbd with a newer winbindd
    >>- Make it possible to use a new smbd against an older winbindd


    A concrete suggestion: belt and suspenders.

    Change the production makefiles to link to winbindd_whatever.so.1 (belt)

    Create a winbindd_whatever.so.2, and build it with the new interfaces,
    using symbol versioning in such a way that linkers that don't
    understand get the new and and not the old versions. (suspenders)

    Change the Makefile for development version and optionally the
    winbindd_whatever.so symlink to point
    to winbindd_whatever.so.2 so that new builds get the new library.

    Now experiment with new interfaces and versioning, knowing that
    old builds won't trip over the new code.

    --dave
    --
    David Collier-Brown | Always do right. This will gratify
    Sun Microsystems, Toronto | some people and astonish the rest
    davecb@sun.com | -- Mark Twain
    (905) 943-1983, cell: (647) 833-9377, (800) 555-9786 x56583
    bridge: (877) 385-4099 code: 506 9191#


  18. Please vote! (Re: Symbol versioning)

    Hi *,

    >>> We can still use a different way and update the library version
    >>> and have compat libraries to handle updates

    >> So now we have two different mechanisms to maintain. Wonderful.

    >
    > The things I would like to have are these:
    >
    > - Make it possible to use an old smbd with a newer winbindd
    > - Make it possible to use a new smbd against an older winbindd
    >
    > Using symbol versioning makes that easy, as the binary always
    > links against the same library soname. So a new smbd would still
    > load with an old libwbclient, because the soname of the new library
    > is the same and smbd only uses functions of the old interface
    > and has references to the old versioned symbols only.
    > Other tools like wbinfo would not be able to load with an old
    > library as it will also have references to new functions.
    >
    > But as we've currently symbol versioning only when using gnu ld
    > it's not available on every platform we support.
    >
    > We could also work with compat libraries (as you proposed, but)
    > in both directions, one compat library that provides the old interfaces
    > against a new library and also a library that provides the new interface
    > against an old library implementing the new functions as stubs
    > returning WBC_ERR_NOT_IMPLEMENTED.
    >
    > I'm currently doing some testing with compat libraries and
    > they may have also some portability problems, I'll continue
    > some testing tomorrow and will come back with the results then.
    >
    > If the compat libraries support all we need, we can think about
    > removing symbol versioning and create a rc2 release...ok?


    I've done some further testing with compat libraries.
    And they work fine, but only without symbol versioning.
    Compat libraries together with symbol versioning works for some cases
    and maybe there's some more magic to get it working for every case,
    but I don't nḱnow a solution yet:-(

    I'm fine with removing symbol versioning again...

    So please vote now, what we should do.

    metze


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

    iD8DBQFISCMRm70gjA5TCD8RAlYVAKDIs2gPy4dcZTAls/wfJJb3wBc5VgCfSHNN
    pGldyBOYblqgw1ArTjAIjzw=
    =wFma
    -----END PGP SIGNATURE-----


  19. Re: Please vote! (Re: Symbol versioning)

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Stefan (metze) Metzmacher wrote:

    > I've done some further testing with compat libraries.
    > And they work fine, but only without symbol versioning.
    > Compat libraries together with symbol versioning works for some cases
    > and maybe there's some more magic to get it working for every case,
    > but I don't nḱnow a solution yet:-(
    >
    > I'm fine with removing symbol versioning again...
    >
    > So please vote now, what we should do.


    I would vote to have a single solution that does not
    require GNU ld (vote to remove the GNU ld symbol versioning).



    jerry

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFISEg9IR7qMdg1EfYRAjPZAJ913QDLx4OMudmt2O6iJH 5oeEQB/gCglczn
    S0Jez2vQ9ibWId/tq9Sb82s=
    =j7LA
    -----END PGP SIGNATURE-----


  20. RE: Please vote! (Re: Symbol versioning)

    1. Please do not require GNU ld.

    2. Please support static linking.

    3. Please do not require symbol versioning.

    VOS does not use GNU ld. We don't have symbol versioning. We don't even
    have static linking (yet). I expect we'll have it within the year or so,
    but we are not planning on implementing symbol versioning.

    Thanks
    PG
    --
    Paul Green, Senior Technical Consultant, Stratus Technologies.
    Voice: +1 978-461-7557; FAX: +1 978-461-3610; Mobile: +1 (978) 235-2451;
    AIM: PaulGreen


+ Reply to Thread
Page 1 of 2 1 2 LastLast