* [PATCH] libv4l: fixup lfs mismatch in preload libraries @ 2018-07-11 13:22 Ezequiel Garcia 2018-07-11 14:55 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 7+ messages in thread From: Ezequiel Garcia @ 2018-07-11 13:22 UTC (permalink / raw) To: linux-media; +Cc: Hans Verkuil, Peter Korsgaard, Ezequiel Garcia From: Peter Korsgaard <jacmet@sunsite.dk> Ensure that the lfs variants are not transparently used instead of the !lfs ones so both can be wrapped, independently of any custom CFLAGS/CPPFLAGS. Without this patch, the following assembler errors appear during cross-compiling with Buildroot: /tmp/ccc3gdJg.s: Assembler messages: /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> --- lib/libv4l1/v4l1compat.c | 3 +++ lib/libv4l2/v4l2convert.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c index cb79629ff88f..e5c9e56261e2 100644 --- a/lib/libv4l1/v4l1compat.c +++ b/lib/libv4l1/v4l1compat.c @@ -19,6 +19,9 @@ # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA */ +/* ensure we see *64 variants and they aren't transparently used */ +#undef _LARGEFILE_SOURCE +#undef _FILE_OFFSET_BITS #define _LARGEFILE64_SOURCE 1 #include <config.h> diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c index 7c9a04c086ed..13ca4cfb1b08 100644 --- a/lib/libv4l2/v4l2convert.c +++ b/lib/libv4l2/v4l2convert.c @@ -23,6 +23,9 @@ /* prevent GCC 4.7 inlining error */ #undef _FORTIFY_SOURCE +/* ensure we see *64 variants and they aren't transparently used */ +#undef _LARGEFILE_SOURCE +#undef _FILE_OFFSET_BITS #define _LARGEFILE64_SOURCE 1 #ifdef ANDROID -- 2.18.0.rc2 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] libv4l: fixup lfs mismatch in preload libraries 2018-07-11 13:22 [PATCH] libv4l: fixup lfs mismatch in preload libraries Ezequiel Garcia @ 2018-07-11 14:55 ` Mauro Carvalho Chehab 2018-07-11 19:38 ` Baruch Siach 0 siblings, 1 reply; 7+ messages in thread From: Mauro Carvalho Chehab @ 2018-07-11 14:55 UTC (permalink / raw) To: Ezequiel Garcia; +Cc: linux-media, Hans Verkuil, Peter Korsgaard Em Wed, 11 Jul 2018 10:22:51 -0300 Ezequiel Garcia <ezequiel@collabora.com> escreveu: > From: Peter Korsgaard <jacmet@sunsite.dk> > > Ensure that the lfs variants are not transparently used instead of the !lfs > ones so both can be wrapped, independently of any custom CFLAGS/CPPFLAGS. > > Without this patch, the following assembler errors appear > during cross-compiling with Buildroot: > > /tmp/ccc3gdJg.s: Assembler messages: > /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined > /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined > > Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> > --- > lib/libv4l1/v4l1compat.c | 3 +++ > lib/libv4l2/v4l2convert.c | 3 +++ > 2 files changed, 6 insertions(+) > > diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c > index cb79629ff88f..e5c9e56261e2 100644 > --- a/lib/libv4l1/v4l1compat.c > +++ b/lib/libv4l1/v4l1compat.c > @@ -19,6 +19,9 @@ > # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA > */ > > +/* ensure we see *64 variants and they aren't transparently used */ > +#undef _LARGEFILE_SOURCE > +#undef _FILE_OFFSET_BITS Hmm... shouldn't this be autodetected? I didn't check anything, but I would be expecting that different distros (and BSD) may be doing different things here, specially if they use different gcc versions or even different libc implementations. > #define _LARGEFILE64_SOURCE 1 > > #include <config.h> > diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c > index 7c9a04c086ed..13ca4cfb1b08 100644 > --- a/lib/libv4l2/v4l2convert.c > +++ b/lib/libv4l2/v4l2convert.c > @@ -23,6 +23,9 @@ > /* prevent GCC 4.7 inlining error */ > #undef _FORTIFY_SOURCE > > +/* ensure we see *64 variants and they aren't transparently used */ > +#undef _LARGEFILE_SOURCE > +#undef _FILE_OFFSET_BITS > #define _LARGEFILE64_SOURCE 1 > > #ifdef ANDROID Thanks, Mauro ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] libv4l: fixup lfs mismatch in preload libraries 2018-07-11 14:55 ` Mauro Carvalho Chehab @ 2018-07-11 19:38 ` Baruch Siach 2018-07-11 22:57 ` Ezequiel Garcia 2018-07-12 8:54 ` Mauro Carvalho Chehab 0 siblings, 2 replies; 7+ messages in thread From: Baruch Siach @ 2018-07-11 19:38 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Ezequiel Garcia, linux-media, Hans Verkuil, Peter Korsgaard, Peter Korsgaard Hi Mauro, Added Peter's updated address to Cc. Mauro Carvalho Chehab writes: > Em Wed, 11 Jul 2018 10:22:51 -0300 > Ezequiel Garcia <ezequiel@collabora.com> escreveu: > >> From: Peter Korsgaard <jacmet@sunsite.dk> >> >> Ensure that the lfs variants are not transparently used instead of the !lfs >> ones so both can be wrapped, independently of any custom CFLAGS/CPPFLAGS. >> >> Without this patch, the following assembler errors appear >> during cross-compiling with Buildroot: >> >> /tmp/ccc3gdJg.s: Assembler messages: >> /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined >> /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined >> >> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> >> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> >> --- >> lib/libv4l1/v4l1compat.c | 3 +++ >> lib/libv4l2/v4l2convert.c | 3 +++ >> 2 files changed, 6 insertions(+) >> >> diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c >> index cb79629ff88f..e5c9e56261e2 100644 >> --- a/lib/libv4l1/v4l1compat.c >> +++ b/lib/libv4l1/v4l1compat.c >> @@ -19,6 +19,9 @@ >> # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA >> */ >> >> +/* ensure we see *64 variants and they aren't transparently used */ >> +#undef _LARGEFILE_SOURCE >> +#undef _FILE_OFFSET_BITS > > Hmm... shouldn't this be autodetected? I didn't check anything, > but I would be expecting that different distros (and BSD) may be > doing different things here, specially if they use different gcc > versions or even different libc implementations. See Peter's explanation here: http://lists.busybox.net/pipermail/buildroot/2017-December/210067.html baruch >> #define _LARGEFILE64_SOURCE 1 >> >> #include <config.h> >> diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c >> index 7c9a04c086ed..13ca4cfb1b08 100644 >> --- a/lib/libv4l2/v4l2convert.c >> +++ b/lib/libv4l2/v4l2convert.c >> @@ -23,6 +23,9 @@ >> /* prevent GCC 4.7 inlining error */ >> #undef _FORTIFY_SOURCE >> >> +/* ensure we see *64 variants and they aren't transparently used */ >> +#undef _LARGEFILE_SOURCE >> +#undef _FILE_OFFSET_BITS >> #define _LARGEFILE64_SOURCE 1 >> >> #ifdef ANDROID -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] libv4l: fixup lfs mismatch in preload libraries 2018-07-11 19:38 ` Baruch Siach @ 2018-07-11 22:57 ` Ezequiel Garcia 2018-07-12 8:54 ` Mauro Carvalho Chehab 1 sibling, 0 replies; 7+ messages in thread From: Ezequiel Garcia @ 2018-07-11 22:57 UTC (permalink / raw) To: Baruch Siach, Mauro Carvalho Chehab Cc: linux-media, Hans Verkuil, Peter Korsgaard, Peter Korsgaard On Wed, 2018-07-11 at 22:38 +0300, Baruch Siach wrote: > Hi Mauro, > > Added Peter's updated address to Cc. > > Mauro Carvalho Chehab writes: > > Em Wed, 11 Jul 2018 10:22:51 -0300 > > Ezequiel Garcia <ezequiel@collabora.com> escreveu: > > > > > From: Peter Korsgaard <jacmet@sunsite.dk> > > > > > > Ensure that the lfs variants are not transparently used instead > > > of the !lfs > > > ones so both can be wrapped, independently of any custom > > > CFLAGS/CPPFLAGS. > > > > > > Without this patch, the following assembler errors appear > > > during cross-compiling with Buildroot: > > > > > > /tmp/ccc3gdJg.s: Assembler messages: > > > /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined > > > /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined > > > > > > Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> > > > Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> > > > --- > > > lib/libv4l1/v4l1compat.c | 3 +++ > > > lib/libv4l2/v4l2convert.c | 3 +++ > > > 2 files changed, 6 insertions(+) > > > > > > diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c > > > index cb79629ff88f..e5c9e56261e2 100644 > > > --- a/lib/libv4l1/v4l1compat.c > > > +++ b/lib/libv4l1/v4l1compat.c > > > @@ -19,6 +19,9 @@ > > > # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, > > > MA 02110-1335 USA > > > */ > > > > > > +/* ensure we see *64 variants and they aren't transparently used > > > */ > > > +#undef _LARGEFILE_SOURCE > > > +#undef _FILE_OFFSET_BITS > > > > Hmm... shouldn't this be autodetected? I didn't check anything, > > but I would be expecting that different distros (and BSD) may be > > doing different things here, specially if they use different gcc > > versions or even different libc implementations. > > See Peter's explanation here: > > http://lists.busybox.net/pipermail/buildroot/2017-December/210067.h > tml > > Nice, thanks for Ccing the real Peter and for adding the link to the discussion. Regards, Eze ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] libv4l: fixup lfs mismatch in preload libraries 2018-07-11 19:38 ` Baruch Siach 2018-07-11 22:57 ` Ezequiel Garcia @ 2018-07-12 8:54 ` Mauro Carvalho Chehab 2018-07-12 19:13 ` Baruch Siach 1 sibling, 1 reply; 7+ messages in thread From: Mauro Carvalho Chehab @ 2018-07-12 8:54 UTC (permalink / raw) To: Baruch Siach Cc: Ezequiel Garcia, linux-media, Hans Verkuil, Peter Korsgaard, Peter Korsgaard Em Wed, 11 Jul 2018 22:38:56 +0300 Baruch Siach <baruch@tkos.co.il> escreveu: > Hi Mauro, > > Added Peter's updated address to Cc. > > Mauro Carvalho Chehab writes: > > Em Wed, 11 Jul 2018 10:22:51 -0300 > > Ezequiel Garcia <ezequiel@collabora.com> escreveu: > > > >> From: Peter Korsgaard <jacmet@sunsite.dk> > >> > >> Ensure that the lfs variants are not transparently used instead of the !lfs > >> ones so both can be wrapped, independently of any custom CFLAGS/CPPFLAGS. > >> > >> Without this patch, the following assembler errors appear > >> during cross-compiling with Buildroot: > >> > >> /tmp/ccc3gdJg.s: Assembler messages: > >> /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined > >> /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined > >> > >> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> > >> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> > >> --- > >> lib/libv4l1/v4l1compat.c | 3 +++ > >> lib/libv4l2/v4l2convert.c | 3 +++ > >> 2 files changed, 6 insertions(+) > >> > >> diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c > >> index cb79629ff88f..e5c9e56261e2 100644 > >> --- a/lib/libv4l1/v4l1compat.c > >> +++ b/lib/libv4l1/v4l1compat.c > >> @@ -19,6 +19,9 @@ > >> # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA > >> */ > >> > >> +/* ensure we see *64 variants and they aren't transparently used */ > >> +#undef _LARGEFILE_SOURCE > >> +#undef _FILE_OFFSET_BITS > > > > Hmm... shouldn't this be autodetected? I didn't check anything, > > but I would be expecting that different distros (and BSD) may be > > doing different things here, specially if they use different gcc > > versions or even different libc implementations. > > See Peter's explanation here: > > http://lists.busybox.net/pipermail/buildroot/2017-December/210067.html The link Peter provided seems to be specific to glibc. The main point I want to bring is: would this change affect users with other setups? There are some users that compile it against FreeBSD and Android. Some compile using dietlibc or uclibc. Also, people build it against 32-bits and 64-bits on x86, arm and other archs. So, the question is: are you sure that the above change is also valid for *all* other environments? If not, I would be expecting it to be attached to some automake test, to be sure that it will be applied only to the affected setups. > > baruch > > >> #define _LARGEFILE64_SOURCE 1 > >> > >> #include <config.h> > >> diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c > >> index 7c9a04c086ed..13ca4cfb1b08 100644 > >> --- a/lib/libv4l2/v4l2convert.c > >> +++ b/lib/libv4l2/v4l2convert.c > >> @@ -23,6 +23,9 @@ > >> /* prevent GCC 4.7 inlining error */ > >> #undef _FORTIFY_SOURCE > >> > >> +/* ensure we see *64 variants and they aren't transparently used */ > >> +#undef _LARGEFILE_SOURCE > >> +#undef _FILE_OFFSET_BITS > >> #define _LARGEFILE64_SOURCE 1 > >> > >> #ifdef ANDROID > > Thanks, Mauro ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] libv4l: fixup lfs mismatch in preload libraries 2018-07-12 8:54 ` Mauro Carvalho Chehab @ 2018-07-12 19:13 ` Baruch Siach 2018-07-12 20:13 ` Peter Korsgaard 0 siblings, 1 reply; 7+ messages in thread From: Baruch Siach @ 2018-07-12 19:13 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Ezequiel Garcia, linux-media, Hans Verkuil, Peter Korsgaard Mauro Carvalho Chehab writes: > Em Wed, 11 Jul 2018 22:38:56 +0300 > Baruch Siach <baruch@tkos.co.il> escreveu: >> Added Peter's updated address to Cc. >> >> Mauro Carvalho Chehab writes: >> > Em Wed, 11 Jul 2018 10:22:51 -0300 >> > Ezequiel Garcia <ezequiel@collabora.com> escreveu: >> > >> >> From: Peter Korsgaard <jacmet@sunsite.dk> >> >> >> >> Ensure that the lfs variants are not transparently used instead of the !lfs >> >> ones so both can be wrapped, independently of any custom CFLAGS/CPPFLAGS. >> >> >> >> Without this patch, the following assembler errors appear >> >> during cross-compiling with Buildroot: >> >> >> >> /tmp/ccc3gdJg.s: Assembler messages: >> >> /tmp/ccc3gdJg.s:67: Error: symbol `open64' is already defined >> >> /tmp/ccc3gdJg.s:130: Error: symbol `mmap64' is already defined >> >> >> >> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> >> >> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> >> >> --- >> >> lib/libv4l1/v4l1compat.c | 3 +++ >> >> lib/libv4l2/v4l2convert.c | 3 +++ >> >> 2 files changed, 6 insertions(+) >> >> >> >> diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c >> >> index cb79629ff88f..e5c9e56261e2 100644 >> >> --- a/lib/libv4l1/v4l1compat.c >> >> +++ b/lib/libv4l1/v4l1compat.c >> >> @@ -19,6 +19,9 @@ >> >> # Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA >> >> */ >> >> >> >> +/* ensure we see *64 variants and they aren't transparently used */ >> >> +#undef _LARGEFILE_SOURCE >> >> +#undef _FILE_OFFSET_BITS >> > >> > Hmm... shouldn't this be autodetected? I didn't check anything, >> > but I would be expecting that different distros (and BSD) may be >> > doing different things here, specially if they use different gcc >> > versions or even different libc implementations. >> >> See Peter's explanation here: >> >> http://lists.busybox.net/pipermail/buildroot/2017-December/210067.html > > The link Peter provided seems to be specific to glibc. The main > point I want to bring is: would this change affect users with > other setups? There are some users that compile it against FreeBSD > and Android. Some compile using dietlibc or uclibc. Also, people > build it against 32-bits and 64-bits on x86, arm and other archs. > > So, the question is: are you sure that the above change is also valid for > *all* other environments? If not, I would be expecting it to be > attached to some automake test, to be sure that it will be applied > only to the affected setups. Buildroot has been carrying this patch since 2012[1] with no one complaining. Buildroot supports glibc, uClibc, and musl libc on a wide range of architectures (x86, ARM, MIPS, PowerPC, Sparc, xtensa, arc, and more) both 32-bit and 64-bit. I don't know about FreeBSD. baruch [1] https://git.buildroot.org/buildroot/commit/?id=d059b1cc61dcafde47723c45b834409026a39dbe >> >> #define _LARGEFILE64_SOURCE 1 >> >> >> >> #include <config.h> >> >> diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c >> >> index 7c9a04c086ed..13ca4cfb1b08 100644 >> >> --- a/lib/libv4l2/v4l2convert.c >> >> +++ b/lib/libv4l2/v4l2convert.c >> >> @@ -23,6 +23,9 @@ >> >> /* prevent GCC 4.7 inlining error */ >> >> #undef _FORTIFY_SOURCE >> >> >> >> +/* ensure we see *64 variants and they aren't transparently used */ >> >> +#undef _LARGEFILE_SOURCE >> >> +#undef _FILE_OFFSET_BITS >> >> #define _LARGEFILE64_SOURCE 1 >> >> >> >> #ifdef ANDROID -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] libv4l: fixup lfs mismatch in preload libraries 2018-07-12 19:13 ` Baruch Siach @ 2018-07-12 20:13 ` Peter Korsgaard 0 siblings, 0 replies; 7+ messages in thread From: Peter Korsgaard @ 2018-07-12 20:13 UTC (permalink / raw) To: Baruch Siach Cc: Mauro Carvalho Chehab, Ezequiel Garcia, linux-media, Hans Verkuil >>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes: Hi, >> The link Peter provided seems to be specific to glibc. The main >> point I want to bring is: would this change affect users with >> other setups? There are some users that compile it against FreeBSD >> and Android. Some compile using dietlibc or uclibc. Also, people >> build it against 32-bits and 64-bits on x86, arm and other archs. >> >> So, the question is: are you sure that the above change is also valid for >> *all* other environments? If not, I would be expecting it to be >> attached to some automake test, to be sure that it will be applied >> only to the affected setups. > Buildroot has been carrying this patch since 2012[1] with no one > complaining. Buildroot supports glibc, uClibc, and musl libc on a wide > range of architectures (x86, ARM, MIPS, PowerPC, Sparc, xtensa, arc, and > more) both 32-bit and 64-bit. Indeed. I believe these comes from the single UNIX specification: http://www.unix.org/version2/whatsnew/lfs20mar.html#3.3 And these defines are what the AC_SYS_LARGEFILE autoconf macro uses: https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/System-Services.html -- Bye, Peter Korsgaard ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-07-12 20:24 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-07-11 13:22 [PATCH] libv4l: fixup lfs mismatch in preload libraries Ezequiel Garcia 2018-07-11 14:55 ` Mauro Carvalho Chehab 2018-07-11 19:38 ` Baruch Siach 2018-07-11 22:57 ` Ezequiel Garcia 2018-07-12 8:54 ` Mauro Carvalho Chehab 2018-07-12 19:13 ` Baruch Siach 2018-07-12 20:13 ` Peter Korsgaard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox