All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Akihiko Odaki <akihiko.odaki@gmail.com>,
	Will Cohen <wwcohen@gmail.com>,
	Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>, Greg Kurz <groug@kaod.org>,
	hi@alyssa.is, Michael Roitzsch <reactorcontrol@icloud.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Keno Fischer <keno@juliacomputing.com>
Subject: Re: [PATCH v5 09/11] 9p: darwin: Implement compatibility for mknodat
Date: Wed, 09 Feb 2022 15:08:35 +0100	[thread overview]
Message-ID: <7028769.ONZ7M9ntUb@silver> (raw)
In-Reply-To: <CAMVc7JXB4KUFbMDekXiVTVqT_UQVpy-y6C+Z8caaSC3FRwPjWg@mail.gmail.com>

On Mittwoch, 9. Februar 2022 14:33:25 CET Akihiko Odaki wrote:
> > I like the idea of switching it to __attribute__((weak)). I should note
> > that I'm not sure that I can actually fully test this out since I'm
> > getting stuck with the linker noting my undefined fake function during
> > the build, but the idea does make logical sense to me for the future fail
> > case and the happy case builds again when implemented with actual
> > pthread_fchdir_np:
> > 
> > [1075/2909] Linking target qemu-nbd
> > FAILED: qemu-nbd
> > cc -m64 -mcx16  -o qemu-nbd qemu-nbd.p/qemu-nbd.c.o -Wl,-dead_strip_dylibs
> > -Wl,-headerpad_max_install_names -Wl,-undefined,error -Wl,-force_load
> > libblockdev.fa -Wl,-force_load libblock.fa -Wl,-force_load libcrypto.fa
> > -Wl,-force_load libauthz.fa -Wl,-force_load libqom.fa -Wl,-force_load
> > libio.fa -fstack-protector-strong
> > -Wl,-rpath,/usr/local/Cellar/gnutls/3.7.3/lib
> > -Wl,-rpath,/usr/local/Cellar/pixman/0.40.0/lib libqemuutil.a
> > libblockdev.fa libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa
> > @block.syms /usr/local/Cellar/gnutls/3.7.3/lib/libgnutls.dylib -lutil
> > -L/usr/local/Cellar/glib/2.70.3/lib -L/usr/local/opt/gettext/lib
> > -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl
> > -L/usr/local/Cellar/glib/2.70.3/lib -L/usr/local/opt/gettext/lib
> > -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lm
> > -L/usr/local/Cellar/glib/2.70.3/lib -L/usr/local/opt/gettext/lib
> > -lgmodule-2.0 -lglib-2.0 -lintl
> > /usr/local/Cellar/pixman/0.40.0/lib/libpixman-1.dylib -lz -lxml2
> > -framework CoreFoundation -framework IOKit -lcurl
> > -L/usr/local/Cellar/glib/2.70.3/lib -L/usr/local/opt/gettext/lib
> > -lgmodule-2.0 -lglib-2.0 -lintl -lbz2
> > /usr/local/Cellar/libssh/0.9.6/lib/libssh.dylib -lpam> 
> > Undefined symbols for architecture x86_64:
> >   "_pthread_fchdir_npfoo", referenced from:
> >       _qemu_mknodat in libblockdev.fa(os-posix.c.o)
> > 
> > ld: symbol(s) not found for architecture x86_64
> > clang: error: linker command failed with exit code 1 (use -v to see
> > invocation) ninja: build stopped: subcommand failed.
> > make[1]: *** [run-ninja] Error 1
> > make: *** [all] Error 2
> > 
> > With that caveat re testing in mind, unless there's another recommended
> > path forward, I think it makes sense to stick with __attribute__((weak))
> > and prepare v6 which incorporates this and all the other feedback from
> > this round.
> __attribute__((weak_import)), which explicitly marks the function as
> external, is more appropriate here. It is feature-equivalent with the
> availability attribute when the minimum deployment target is lower
> than the version which introduced the function.

Thanks for chiming in on this macOS issue Akihiko!

Are you sure that "weak_import" is still the preferred way? From behaviour PoV 
I do not see any difference at all. I can't even tell what the intended 
difference was, and QEMU currently only seems to use "weak" in the entire code 
base.

Googling around, "weak_import" seems to be required on ancient OS X versions 
only and that it's now deprecated in favour of the more common "weak", no?

Best regards,
Christian Schoenebeck




  reply	other threads:[~2022-02-09 15:26 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-07 22:40 [PATCH v5 00/11] 9p: Add support for darwin Will Cohen
2022-02-07 22:40 ` [PATCH v5 01/11] 9p: linux: Fix a couple Linux assumptions Will Cohen
2022-02-07 22:40 ` [PATCH v5 02/11] 9p: Rename 9p-util -> 9p-util-linux Will Cohen
2022-02-07 22:40 ` [PATCH v5 03/11] 9p: darwin: Handle struct stat(fs) differences Will Cohen
2022-02-07 22:40 ` [PATCH v5 04/11] 9p: darwin: Handle struct dirent differences Will Cohen
2022-02-07 22:40 ` [PATCH v5 05/11] 9p: darwin: Ignore O_{NOATIME, DIRECT} Will Cohen
2022-02-07 22:40 ` [PATCH v5 06/11] 9p: darwin: Move XATTR_SIZE_MAX->P9_XATTR_SIZE_MAX Will Cohen
2022-02-08 12:20   ` Christian Schoenebeck
2022-02-08 13:45     ` Will Cohen
2022-02-07 22:40 ` [PATCH v5 07/11] 9p: darwin: *xattr_nofollow implementations Will Cohen
2022-02-07 22:40 ` [PATCH v5 08/11] 9p: darwin: Compatibility for f/l*xattr Will Cohen
2022-02-07 22:40 ` [PATCH v5 09/11] 9p: darwin: Implement compatibility for mknodat Will Cohen
2022-02-07 22:56   ` Christian Schoenebeck
2022-02-08 13:36     ` Will Cohen
2022-02-08 15:02       ` Christian Schoenebeck
2022-02-08 15:57         ` Will Cohen
2022-02-08 16:11           ` Christian Schoenebeck
2022-02-08 16:19             ` Will Cohen
2022-02-08 18:04               ` Will Cohen
2022-02-08 18:28                 ` Christian Schoenebeck
2022-02-08 19:48                   ` Christian Schoenebeck
2022-02-08 22:57                     ` Will Cohen
2022-02-09 13:33                       ` Akihiko Odaki
2022-02-09 14:08                         ` Christian Schoenebeck [this message]
2022-02-09 18:20                           ` Will Cohen
2022-02-09 23:10                             ` Akihiko Odaki
2022-02-10 15:46                               ` Will Cohen
2022-02-09 13:50                       ` Christian Schoenebeck
2022-02-08 10:55   ` Philippe Mathieu-Daudé via
2022-02-07 22:40 ` [PATCH v5 10/11] 9p: darwin: meson: Allow VirtFS on Darwin Will Cohen
2022-02-07 23:44   ` Christian Schoenebeck
2022-02-07 23:47     ` Will Cohen
2022-02-07 22:40 ` [PATCH v5 11/11] 9p: darwin: Adjust assumption on virtio-9p-test Will Cohen
2022-02-08 10:16   ` Greg Kurz

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=7028769.ONZ7M9ntUb@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=akihiko.odaki@gmail.com \
    --cc=groug@kaod.org \
    --cc=hi@alyssa.is \
    --cc=keno@juliacomputing.com \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=reactorcontrol@icloud.com \
    --cc=thuth@redhat.com \
    --cc=wwcohen@gmail.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.