All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Matthew Weber <matthew.weber@rockwellcollins.com>, fio@vger.kernel.org
Subject: Re: fio-2.1.4 - dlopen failed for libaio
Date: Fri, 05 Sep 2014 09:04:34 -0600	[thread overview]
Message-ID: <5409D102.7090306@kernel.dk> (raw)
In-Reply-To: <CANQCQpamy7TCmgtZBwtzcKH3KMZnJZ1tguPRGr2Xa63Axo3P1w@mail.gmail.com>

On 09/05/2014 07:42 AM, Matthew Weber wrote:
> Status output from a case where fio is built without libaio support....
>      fio: engine libaio not loadable
>      fio: failed to load engine libaio
>      fio: file:ioengines.c:102, func=dlopen, error=libaio: cannot open
> shared object file: No such file or directory
> 
> I don't think this is necessarily a bug, but I wanted to comment on
> what we observed.  There was some discussion on this on the buildroot
> mailing list since we thought we needed to force a dependency on
> having libaio always built as a dependency for the fio package to link
> against.  Instead the user just needs to enable the libaio if they use
> it as an engine (which is fine).
> http://buildroot-busybox.2317881.n4.nabble.com/PATCH-v4-fio-add-missing-libaio-dependency-td77314.html
> 
> Here our interpretation of what's happening.... It looks like the
> shared library open error is one of the expected failure outputs if
> you don't have support for the specific dynamic "io library".  The
> build of the fio package does correctly determine if the libaio lib is
> present or not and correctly adds it to the ioengines list for use (at
> build time, so the enghelp output is correct, etc).  However when fio
> is executed, it looks up if a "set of operations" is registered for
> whichever ioengine library used.  If they are, it goes ahead and uses
> them.  If they need to be loaded, like in the case of libaio, it
> attempts to load them. However there is no check to see if fio was
> built with support for the external library being loaded (like in this
> case of libaio).

The output could be improved, but it's expected behavior. If you specify
ioengine=someengine, fio will check for an internal engine of that name.
If it doesn't find one, it will attempt to dynamically load an engine
with that file name. When that then fails, you get the above output.
This is no different than if you did ioengine=windowsaio on Linux, or
ioengine=libaio on Windows, for instance.

-- 
Jens Axboe



  reply	other threads:[~2014-09-05 15:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05 13:42 fio-2.1.4 - dlopen failed for libaio Matthew Weber
2014-09-05 15:04 ` Jens Axboe [this message]
2014-09-05 15:19   ` Matthew Weber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5409D102.7090306@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=fio@vger.kernel.org \
    --cc=matthew.weber@rockwellcollins.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.