Professional Web Applications Themes

Manually deploying dylib - Mac Programming

Hi, My app uses libiconv. In MacOS 10.3, that functionality is part of the system. In 10.2 it's not. Since libiconv is a dylib, I need to install it on computers running 10.2. I guess the directory for it is /usr/lib. I know I can install it there programmatically. However, during the testing period, I would like testers to install it manually. Since /usr is invisible, how can this be done ? Is there another place where that dylib could be located for which it is possible to do the install manually ? Eric...

  1. #1

    Default Manually deploying dylib

    Hi,

    My app uses libiconv. In MacOS 10.3, that functionality is part of the
    system. In 10.2 it's not. Since libiconv is a dylib, I need to install it on
    computers running 10.2. I guess the directory for it is /usr/lib.

    I know I can install it there programmatically. However, during the testing
    period, I would like testers to install it manually. Since /usr is
    invisible, how can this be done ?

    Is there another place where that dylib could be located for which it is
    possible to do the install manually ?

    Eric

    Eric Guest

  2. #2

    Default Re: Manually deploying dylib

    Eric VERGNAUD <fr> wrote:
     

    What about the "Go to Folder" command from the Finder and specify
    /usr/lib ... or I am missing something?


    Fabrizio

    f.toso Guest

  3. #3

    Default Re: Manually deploying dylib

    > What about the "Go to Folder" command from the Finder and specify 

    Or type "open /usr/lib" in the Terminal; or write an app that installs
    the library upon clicking an "Install" button. mb.
    M Guest

  4. #4

    Default Re: Manually deploying dylib

    dans l'article 1g63u9e.161b4zk1vz2kg4N%com,
    f.toso à com a écrit le 17/12/03 9:29:
     
    >
    > What about the "Go to Folder" command from the Finder and specify
    > /usr/lib ... or I am missing something?[/ref]

    You're not, I was. I never use this menu, and didn't think it would work
    with invisible folders.

    That did the trick, thanks.

    Eric

    Eric Guest

  5. #5

    Default Re: Manually deploying dylib

    Hi Eric, all,

    Eric VERGNAUD <fr> writes: 

    Related question: Is this really a directory that a third party should
    use?

    My understanding from other Unixes is that /usr/lib is, despite the
    "usr" in there, a directory reserved for the OS vendor. Other Unixes
    would suggest /usr/local/lib or /opt/<appname> instead.

    benny
    Benjamin Guest

  6. #6

    Default Re: Manually deploying dylib

    dans l'article benny.turtle-trading.net, Benjamin
    Riefenstahl à de a écrit le 17/12/03 13:37:
     
    >
    > Related question: Is this really a directory that a third party should
    > use?
    >
    > My understanding from other Unixes is that /usr/lib is, despite the
    > "usr" in there, a directory reserved for the OS vendor. Other Unixes
    > would suggest /usr/local/lib or /opt/<appname> instead.
    >
    > benny[/ref]

    I don't know the answer, but I'm interested. However in my case, the library
    is part of unix.

    Eric

    Eric Guest

  7. #7

    Default Re: Manually deploying dylib

    In <BC05584A.177F7%fr> Eric VERGNAUD wrote: 

    Why don't you put it next to your executable and use install_name_tool ?
    Just run "install_name_tool -id executable_path/libiconv.dylib ~/
    libiconv.dylib"
    and relink with it.

    I think this is the best way.

    arne

    Arne Guest

  8. #8

    Default Re: Manually deploying dylib

    dans l'article 20031217210514882+arcor-ip.de, Arne Scheffler à
    knup.de a écrit le 17/12/03 21:06:
     
    >
    > Why don't you put it next to your executable and use install_name_tool ?
    > Just run "install_name_tool -id executable_path/libiconv.dylib ~/
    > libiconv.dylib"
    > and relink with it.
    >[/ref]

    Maybe I should have mentioned that the testers are end users.
    Obviously you don't expect end users to accept to do that, do you ?

    Eric

    Eric Guest

  9. #9

    Default Re: Manually deploying dylib

    In article <BC067F4A.1786A%fr>,
    Eric VERGNAUD <fr> wrote:
     
    > >
    > > Why don't you put it next to your executable and use install_name_tool ?
    > > Just run "install_name_tool -id executable_path/libiconv.dylib ~/
    > > libiconv.dylib"
    > > and relink with it.
    > >[/ref]
    >
    > Maybe I should have mentioned that the testers are end users.
    > Obviously you don't expect end users to accept to do that, do you ?[/ref]

    Obviously not. Unless I am grossly mistaken, this is a procedure that
    *you* are supposed to do. Its purpose is to allow you to embed the
    ..dylib in your app's bundle. This makes life easier for everybody, and
    makes it so you don't have to do anything evil like provide an installer
    for your application.
    Michael Guest

  10. #10

    Default Re: Manually deploying dylib

    Michael Ash <com> wrote: 
     
    >>
    >> Maybe I should have mentioned that the testers are end users.
    >> Obviously you don't expect end users to accept to do that, do you ?[/ref][/ref]
     

    I'm going to jump in here - this sounds like a great way to get
    my app to run on older OS'es without trying to link to the
    lowest common denominator. Can someone just clarify a few
    things?

    Is executable_path literal? If not, that might cause problems
    when my app moves around, wouldn't it?

    Is ~/libiconv.dylib literal? Wouldn't you specify the path to
    the existing library (in /usr/lib)?

    Cheers
    --
    *--------------------------------------------------------*
    | ^Nothing is foolproof to a sufficiently talented fool^ |
    | Heath Raftery, HRSoftWorks _\|/_ |
    *______________________________________m_('.')_m__ _______*
    Heath Guest

  11. #11

    Default Re: Manually deploying dylib

    In <brqs57$6ll$newcastle.edu.au> Heath Raftery wrote: 
    > [/ref]
    > =E0 [/ref]
    > he [/ref]
    > ll [/ref]
    > ib. [/ref]
    > t [/ref]
    > l ? [/ref]

    > =20 
    >
    > I'm going to jump in here - this sounds like a great way to get
    > my app to run on older OS'es without trying to link to the
    > lowest common denominator. Can someone just clarify a few
    > things?
    >
    > Is executable_path literal? If not, that might cause problems
    > when my app moves around, wouldn't it?[/ref]

    It is a relative path not an absolute one. So it doesn't hurd if you
    move the app.
     


    I would highly suggest to copy the lib somewhere else before you use it
    with install_name_tool.

    arne
    Arne Guest

  12. #12

    Default Re: Manually deploying dylib

    >>> Why don't you put it next to your executable and use install_name_tool ? 
    >>
    >> Maybe I should have mentioned that the testers are end users.
    >> Obviously you don't expect end users to accept to do that, do you ?[/ref]
    >
    > Obviously not. Unless I am grossly mistaken, this is a procedure that
    > *you* are supposed to do. Its purpose is to allow you to embed the
    > .dylib in your app's bundle. This makes life easier for everybody, and
    > makes it so you don't have to do anything evil like provide an installer
    > for your application.[/ref]

    But then I'm carrying that lib (>1M) on 10.3 where I don't need it. That's
    what I'd like to avoid, since I expect a vast majority of users to be on
    Panther. Otherwise I guess I can link with the dylib properly set in
    CodeWarrior.

    Eric

    Eric Guest

  13. #13

    Default Re: Manually deploying dylib

    In article <brqs57$6ll$newcastle.edu.au>,
    Heath Raftery <com> wrote:
     

    The string is literally 'executable_path', and it doesn't refer to a
    fixed location. Instead, the runtime linker resolves it as the location
    of the application that's loading your library.

    For more information, Google for 'executable_path'.

    -Eric

    --
    Eric Albert edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  14. #14

    Default Re: Manually deploying dylib

    In article <BC06D2B9.17897%fr>,
    Eric VERGNAUD <fr> wrote:
     
    > >
    > > Obviously not. Unless I am grossly mistaken, this is a procedure that
    > > *you* are supposed to do. Its purpose is to allow you to embed the
    > > .dylib in your app's bundle. This makes life easier for everybody, and
    > > makes it so you don't have to do anything evil like provide an installer
    > > for your application.[/ref]
    >
    > But then I'm carrying that lib (>1M) on 10.3 where I don't need it. That's
    > what I'd like to avoid, since I expect a vast majority of users to be on
    > Panther. Otherwise I guess I can link with the dylib properly set in
    > CodeWarrior.[/ref]

    The size of your app bundle is nearly irrelevant. What's important is
    the amount of stuff that your end users have to download. They'll have
    to download the same amount of stuff whether the library is part of your
    bundle or if it's in a separate installer.

    A normal app should *never* require an installer on the Mac. If you can
    avoid requiring one, you should.
    Michael Guest

  15. #15

    Default Re: Manually deploying dylib

    dans l'article mail-CAA1B1.12360618122003localhost, Michael Ash à
    com a écrit le 18/12/03 12:36:
     
    >
    > The size of your app bundle is nearly irrelevant. What's important is
    > the amount of stuff that your end users have to download. They'll have
    > to download the same amount of stuff whether the library is part of your
    > bundle or if it's in a separate installer.
    >
    > A normal app should *never* require an installer on the Mac. If you can
    > avoid requiring one, you should.[/ref]

    I agree on the principle, however, my intention was to provide a separate
    installer for the dylib for Jaguar users only.

    Eric

    Eric Guest

  16. #16

    Default Re: Manually deploying dylib

    In article <BC07A266.17949%fr>,
    Eric VERGNAUD <fr> wrote:
     
    > >
    > > The size of your app bundle is nearly irrelevant. What's important is
    > > the amount of stuff that your end users have to download. They'll have
    > > to download the same amount of stuff whether the library is part of your
    > > bundle or if it's in a separate installer.
    > >
    > > A normal app should *never* require an installer on the Mac. If you can
    > > avoid requiring one, you should.[/ref]
    >
    > I agree on the principle, however, my intention was to provide a separate
    > installer for the dylib for Jaguar users only.[/ref]

    In that case, I would say that you should provide a separate app package
    for Jaguar users. It can't be too hard for you to provide, and it's
    certainly no extra burden on the users. They still have to decide which
    things they need to download, but that way your Jaguar users only have
    to download one thing instead of two.
    Michael Guest

Similar Threads

  1. hibernates manually
    By alex in forum Windows XP/2000/ME
    Replies: 2
    Last Post: July 13th, 12:26 PM
  2. Shutting down manually
    By Pascal Schmidt-Volkmar in forum Windows XP/2000/ME
    Replies: 4
    Last Post: July 5th, 07:13 PM
  3. How Do I slice manually?
    By Kay Poe webforumsuser@macromedia.com in forum Macromedia Fireworks
    Replies: 5
    Last Post: July 2nd, 02:51 AM
  4. 817 to 920 Upgrade manually or via DUA
    By Jack in forum Oracle Server
    Replies: 1
    Last Post: June 30th, 12:29 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139