Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On Wed, Apr 27, 2016 at 05:31:43PM -0700, Dave Yeo wrote: > On 04/27/16 04:05 PM, Michael Niedermayer wrote: > >On Tue, Apr 26, 2016 at 06:15:26PM +0300, Dmitriy Kuminov wrote: > >>On 2016-04-26 11:51:28 +, KO Myung-Hun said: > >> > >>>However, ln_s is always set to 'cp -f' on OS/2. Please remove ln_s > >>>overriding codes as well. > >> > >>Yes, but my initial patch already removes this override (check the > >>first hunk) so just applying it + Dave's should get it all done. > > > >which patches exactly should be applied ? > > > > Reattached to avoid confusion. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 04/27/16 04:05 PM, Michael Niedermayer wrote: On Tue, Apr 26, 2016 at 06:15:26PM +0300, Dmitriy Kuminov wrote: On 2016-04-26 11:51:28 +, KO Myung-Hun said: However, ln_s is always set to 'cp -f' on OS/2. Please remove ln_s overriding codes as well. Yes, but my initial patch already removes this override (check the first hunk) so just applying it + Dave's should get it all done. which patches exactly should be applied ? Reattached to avoid confusion. Thanks, Dave From 68addec570bcc9db6f37232523c724e66c004149 Mon Sep 17 00:00:00 2001 From: Dmitriy Kuminov Date: Thu, 14 Apr 2016 01:45:01 +0400 Subject: [PATCH 1/2] configure: Do not create/install versioned DLLs on OS/2. Only one DLL for each module must be present on OS/2: SLIBNAME_WITH_MAJOR (the same as on Windows). Creating other DLLs makes no sense as they can't be used. Signed-off-by: Dave Yeo --- configure | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/configure b/configure index ef0b689..c96b845 100755 --- a/configure +++ b/configure @@ -4716,7 +4716,6 @@ case $target_os in ;; os/2*) strip="lxlite -CS" -ln_s="cp -f" objformat="aout" add_cppflags -D_GNU_SOURCE add_ldflags -Zomf -Zbin-files -Zargs-wild -Zmap @@ -4724,16 +4723,18 @@ case $target_os in LIBSUF="_s.a" SLIBPREF="" SLIBSUF=".dll" -SLIBNAME_WITH_VERSION='$(SLIBPREF)$(NAME)-$(LIBVERSION)$(SLIBSUF)' -SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(shell echo $(NAME) | cut -c1-6)$(LIBMAJOR)$(SLIBSUF)' -SLIB_CREATE_DEF_CMD='echo LIBRARY $(SLIBNAME_WITH_MAJOR) INITINSTANCE TERMINSTANCE > $(SUBDIR)$(NAME).def; \ -echo CODE PRELOAD MOVEABLE DISCARDABLE >> $(SUBDIR)$(NAME).def; \ -echo DATA PRELOAD MOVEABLE MULTIPLE NONSHARED >> $(SUBDIR)$(NAME).def; \ -echo EXPORTS >> $(SUBDIR)$(NAME).def; \ -emxexp $(OBJS) >> $(SUBDIR)$(NAME).def' -SLIB_EXTRA_CMD='emximp -o $(SUBDIR)$(LIBPREF)$(NAME)_dll.a $(SUBDIR)$(NAME).def; \ -emximp -o $(SUBDIR)$(LIBPREF)$(NAME)_dll.lib $(SUBDIR)$(NAME).def;' -SLIB_INSTALL_EXTRA_LIB='$(LIBPREF)$(NAME)_dll.a $(LIBPREF)$(NAME)_dll.lib' +SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)' +SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(shell echo $(FULLNAME) | cut -c1-6)$(LIBMAJOR)$(SLIBSUF)' +SLIB_CREATE_DEF_CMD='echo LIBRARY $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=) INITINSTANCE TERMINSTANCE > $(SUBDIR)$(FULLNAME).def; \ +echo CODE PRELOAD MOVEABLE DISCARDABLE >> $(SUBDIR)$(FULLNAME).def; \ +echo DATA PRELOAD MOVEABLE MULTIPLE NONSHARED >> $(SUBDIR)$(FULLNAME).def; \ +echo EXPORTS >> $(SUBDIR)$(FULLNAME).def; \ +emxexp $(OBJS) >> $(SUBDIR)$(FULLNAME).def' +SLIB_EXTRA_CMD='emximp -o $(SUBDIR)$(LIBPREF)$(FULLNAME)_dll.a $(SUBDIR)$(FULLNAME).def; \ +emximp -o $(SUBDIR)$(LIBPREF)$(FULLNAME)_dll.lib $(SUBDIR)$(FULLNAME).def;' +SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)' +SLIB_INSTALL_LINKS= +SLIB_INSTALL_EXTRA_LIB='$(LIBPREF)$(FULLNAME)_dll.a $(LIBPREF)$(FULLNAME)_dll.lib' enable dos_paths enable_weak os2threads ;; -- 2.0.0 From 341e82add973c1ff54f93b0eca7278d5958e6b55 Mon Sep 17 00:00:00 2001 From: Dave Yeo Date: Mon, 25 Apr 2016 07:39:08 -0700 Subject: [PATCH 2/2] configure: Allow choice in choosing a symlink command Signed-off-by: Dave Yeo --- configure | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/configure b/configure index c96b845..d75ff04 100755 --- a/configure +++ b/configure @@ -314,6 +314,7 @@ Toolchain options: --nm=NM use nm tool NM [$nm_default] --ar=AR use archive tool AR [$ar_default] --as=AS use assembler AS [$as_default] + --ln_s=LN_S use symbolic link tool LN_S [$ln_s_default] --strip=STRIPuse strip tool STRIP [$strip_default] --windres=WINDRESuse windows resource compiler WINDRES [$windres_default] --yasmexe=EXEuse yasm-compatible assembler EXE [$yasmexe_default] @@ -2137,6 +2138,7 @@ CMDLINE_SET=" host_os install ld +ln_s logfile malloc_prefix nm @@ -3078,7 +3080,7 @@ host_cc_default="gcc" cp_f="cp -f" doxygen_default="doxygen" install="install" -ln_s="ln -s -f" +ln_s_default="ln -s -f" nm_default="nm -g" objformat="elf" pkg_config_default=pkg-config @@ -4001,7 +4003,7 @@ test -n "$cc_type" && enable $cc_type || : ${dep_cc_default:=$cc} : ${ld_default:=$cc} : ${host_ld_default:=$host_cc} -set_default ar as objcc dep_cc ld host_ld windres +set_default ar as objcc dep_cc ld ln_s host_ld windres probe_cc as "$as" asflags_filter=$_flags_filter -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On Tue, Apr 26, 2016 at 06:15:26PM +0300, Dmitriy Kuminov wrote: > On 2016-04-26 11:51:28 +, KO Myung-Hun said: > > >However, ln_s is always set to 'cp -f' on OS/2. Please remove ln_s > >overriding codes as well. > > Yes, but my initial patch already removes this override (check the > first hunk) so just applying it + Dave's should get it all done. which patches exactly should be applied ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-26 11:51:28 +, KO Myung-Hun said: However, ln_s is always set to 'cp -f' on OS/2. Please remove ln_s overriding codes as well. Yes, but my initial patch already removes this override (check the first hunk) so just applying it + Dave's should get it all done. -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
Dave Yeo wrote: > On 04/24/16 05:53 PM, Michael Niedermayer wrote: >> On Sun, Apr 24, 2016 at 11:55:06AM -0700, Dave Yeo wrote: >>> On 04/23/16 12:53 PM, Michael Niedermayer wrote: On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote: >> On 04/20/16 03:48 PM, Dmitriy Kuminov wrote: I do care about consistency, collaboration and prevention of artificial entropy growth. >> >> One option is to make ln_s a configure option, something like the >> attached, which is a work in progress as out of tree builds are >> broken when using cp -p. Almost seems a failure in the code that >> decides whether symlinks work. >> Dave >> this seems not working ./configure ./configure: 4790: ./configure: /tmp/dest_sJUY97zC: Permission denied rm: cannot remove `/tmp/name_cM7p9K1e': No such file or directory >>> >>> It's the correct output (I get similar even before this patch) when >>> $ln_s="cp -p" as it tries to touch a file in a symlinked directory >>> and correctly fails. >> >> there are no error messages before here, also the ln_s and ln_s_default >> are not connected i think >> set_default or similar is missing > > OK, thanks, that's what I missed. > >> >> >>> Did you run make && make install after configuring? >>> Here's the version I'll post later in a new thread, please test. >> >> this seems to apply only "in reverse" > > Strange, wonder how I did that. > New patch which I think along with Dmitriys could be applied if KOMH has > no objections Thanks, Dave. However, ln_s is always set to 'cp -f' on OS/2. Please remove ln_s overriding codes as well. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 04/24/16 05:53 PM, Michael Niedermayer wrote: On Sun, Apr 24, 2016 at 11:55:06AM -0700, Dave Yeo wrote: On 04/23/16 12:53 PM, Michael Niedermayer wrote: On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote: On 04/20/16 03:48 PM, Dmitriy Kuminov wrote: I do care about consistency, collaboration and prevention of artificial entropy growth. One option is to make ln_s a configure option, something like the attached, which is a work in progress as out of tree builds are broken when using cp -p. Almost seems a failure in the code that decides whether symlinks work. Dave this seems not working ./configure ./configure: 4790: ./configure: /tmp/dest_sJUY97zC: Permission denied rm: cannot remove `/tmp/name_cM7p9K1e': No such file or directory It's the correct output (I get similar even before this patch) when $ln_s="cp -p" as it tries to touch a file in a symlinked directory and correctly fails. there are no error messages before here, also the ln_s and ln_s_default are not connected i think set_default or similar is missing OK, thanks, that's what I missed. Did you run make && make install after configuring? Here's the version I'll post later in a new thread, please test. this seems to apply only "in reverse" Strange, wonder how I did that. New patch which I think along with Dmitriys could be applied if KOMH has no objections Dave Dave From 341e82add973c1ff54f93b0eca7278d5958e6b55 Mon Sep 17 00:00:00 2001 From: Dave Yeo Date: Mon, 25 Apr 2016 07:39:08 -0700 Subject: [PATCH 2/2] configure: Allow choice in choosing a symlink command Signed-off-by: Dave Yeo --- configure | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/configure b/configure index c96b845..d75ff04 100755 --- a/configure +++ b/configure @@ -314,6 +314,7 @@ Toolchain options: --nm=NM use nm tool NM [$nm_default] --ar=AR use archive tool AR [$ar_default] --as=AS use assembler AS [$as_default] + --ln_s=LN_S use symbolic link tool LN_S [$ln_s_default] --strip=STRIPuse strip tool STRIP [$strip_default] --windres=WINDRESuse windows resource compiler WINDRES [$windres_default] --yasmexe=EXEuse yasm-compatible assembler EXE [$yasmexe_default] @@ -2137,6 +2138,7 @@ CMDLINE_SET=" host_os install ld +ln_s logfile malloc_prefix nm @@ -3078,7 +3080,7 @@ host_cc_default="gcc" cp_f="cp -f" doxygen_default="doxygen" install="install" -ln_s="ln -s -f" +ln_s_default="ln -s -f" nm_default="nm -g" objformat="elf" pkg_config_default=pkg-config @@ -4001,7 +4003,7 @@ test -n "$cc_type" && enable $cc_type || : ${dep_cc_default:=$cc} : ${ld_default:=$cc} : ${host_ld_default:=$host_cc} -set_default ar as objcc dep_cc ld host_ld windres +set_default ar as objcc dep_cc ld ln_s host_ld windres probe_cc as "$as" asflags_filter=$_flags_filter -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On Sun, Apr 24, 2016 at 11:55:06AM -0700, Dave Yeo wrote: > On 04/23/16 12:53 PM, Michael Niedermayer wrote: > >On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote: > >>>On 04/20/16 03:48 PM, Dmitriy Kuminov wrote: > >I do care about consistency, collaboration and prevention of artificial > >entropy growth. > >>> > >>>One option is to make ln_s a configure option, something like the > >>>attached, which is a work in progress as out of tree builds are > >>>broken when using cp -p. Almost seems a failure in the code that > >>>decides whether symlinks work. > >>>Dave > >>> > >this seems not working > > > >./configure > >./configure: 4790: ./configure: /tmp/dest_sJUY97zC: Permission denied > >rm: cannot remove `/tmp/name_cM7p9K1e': No such file or directory > > > > It's the correct output (I get similar even before this patch) when > $ln_s="cp -p" as it tries to touch a file in a symlinked directory > and correctly fails. there are no error messages before here, also the ln_s and ln_s_default are not connected i think set_default or similar is missing > Did you run make && make install after configuring? > Here's the version I'll post later in a new thread, please test. this seems to apply only "in reverse" > Dave > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 04/23/16 12:53 PM, Michael Niedermayer wrote: On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote: >On 04/20/16 03:48 PM, Dmitriy Kuminov wrote: > >I do care about consistency, collaboration and prevention of artificial > >entropy growth. > >One option is to make ln_s a configure option, something like the >attached, which is a work in progress as out of tree builds are >broken when using cp -p. Almost seems a failure in the code that >decides whether symlinks work. >Dave > this seems not working ./configure ./configure: 4790: ./configure: /tmp/dest_sJUY97zC: Permission denied rm: cannot remove `/tmp/name_cM7p9K1e': No such file or directory It's the correct output (I get similar even before this patch) when $ln_s="cp -p" as it tries to touch a file in a symlinked directory and correctly fails. Did you run make && make install after configuring? Here's the version I'll post later in a new thread, please test. Dave From 5604d27e7af75a61c4ee249c753fd617aca3f8bd Mon Sep 17 00:00:00 2001 From: Dave Yeo Date: Sun, 24 Apr 2016 11:08:53 -0700 Subject: [PATCH] configure: Allow choice in choosing a symlink command Signed-off-by: Dave Yeo --- configure | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/configure b/configure index 52ae9c5..8801729 100755 --- a/configure +++ b/configure @@ -4789,12 +4789,12 @@ esac link_dest=$(mktemp -u $TMPDIR/dest_) link_name=$(mktemp -u $TMPDIR/name_) mkdir "$link_dest" -$ln_s_default "$link_dest" "$link_name" +$ln_s "$link_dest" "$link_name" touch "$link_dest/test_file" if [ "$source_path" != "." ] && ([ ! -d src ] || [ -L src ]) && [ -e "$link_name/test_file" ]; then # create link to source path [ -e src ] && rm src -$ln_s_default "$source_path" src +$ln_s "$source_path" src source_link=src else # creating directory links doesn't work @@ -6409,7 +6409,7 @@ AR_O=$ar_o RANLIB=$ranlib STRIP=$strip CP=cp -p -LN_S=$ln_s_default +LN_S=$ln_s CPPFLAGS=$CPPFLAGS CFLAGS=$CFLAGS CXXFLAGS=$CXXFLAGS -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote: > On 04/20/16 03:48 PM, Dmitriy Kuminov wrote: > >I do care about consistency, collaboration and prevention of artificial > >entropy growth. > > One option is to make ln_s a configure option, something like the > attached, which is a work in progress as out of tree builds are > broken when using cp -p. Almost seems a failure in the code that > decides whether symlinks work. > Dave > this seems not working ./configure ./configure: 4790: ./configure: /tmp/dest_sJUY97zC: Permission denied rm: cannot remove `/tmp/name_cM7p9K1e': No such file or directory > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-21 00:05:57 +, Michael Niedermayer said: On Thu, Apr 21, 2016 at 01:48:22AM +0300, Dmitriy Kuminov wrote: you all want the same, a perfect solution iam sure you can reach some consensus about what to do and work together to do it. Iam happy to apply whatever patch the OS/2 people agree about. Ok, expected this answer. That sounds fair and sane. We can also give direct write access to some OS/2 developer to simplify OS/2 maintaince when theres agreement/consensus on who will do the OS/2 - FFmpeg maintaince work Okay, I hope we will sort that out and let you know then. -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 04/20/16 03:48 PM, Dmitriy Kuminov wrote: I do care about consistency, collaboration and prevention of artificial entropy growth. One option is to make ln_s a configure option, something like the attached, which is a work in progress as out of tree builds are broken when using cp -p. Almost seems a failure in the code that decides whether symlinks work. Dave From 3bd0a41b29b7c9abf0bededff643c48511d7611b Mon Sep 17 00:00:00 2001 From: Dave Yeo Date: Wed, 20 Apr 2016 21:24:32 -0700 Subject: [PATCH 2/2] configure: Allow choice in choosing a symlink command Signed-off-by: Dave Yeo --- configure | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 699f2c8..1c7e9ad 100755 --- a/configure +++ b/configure @@ -314,6 +314,7 @@ Toolchain options: --nm=NM use nm tool NM [$nm_default] --ar=AR use archive tool AR [$ar_default] --as=AS use assembler AS [$as_default] + --ln_s=LN_S use symbolic link command [$ln_s_default] --strip=STRIPuse strip tool STRIP [$strip_default] --windres=WINDRESuse windows resource compiler WINDRES [$windres_default] --yasmexe=EXEuse yasm-compatible assembler EXE [$yasmexe_default] @@ -2137,6 +2138,7 @@ CMDLINE_SET=" host_os install ld +ln_s logfile malloc_prefix nm @@ -3077,7 +3079,7 @@ host_cc_default="gcc" cp_f="cp -f" doxygen_default="doxygen" install="install" -ln_s="ln -s -f" +ln_s_default="ln -s -f" nm_default="nm -g" objformat="elf" pkg_config_default=pkg-config -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On Thu, Apr 21, 2016 at 01:48:22AM +0300, Dmitriy Kuminov wrote: > On 2016-04-20 11:48:33 +, KO Myung-Hun said: [...] > A question to maintainers with commit rights: please clarify, what > should I do to have my patches applied? you all want the same, a perfect solution iam sure you can reach some consensus about what to do and work together to do it. Iam happy to apply whatever patch the OS/2 people agree about. We can also give direct write access to some OS/2 developer to simplify OS/2 maintaince when theres agreement/consensus on who will do the OS/2 - FFmpeg maintaince work [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-20 11:48:33 +, KO Myung-Hun said: No, it's not because ln_s overriding is already there. And there is just no need to replace it. Wrong. "There is no need" sounds like if it were the truth but in fact it's not, it's just your opinion. Did you present any real-life cases where not using symlinks in FFmpeg development hurts ? Yes, I did. In detail. Please read my previous message closer. However, Dave reported some failure cases due to removing ln_s overriding. Where did he do that? I didn't see it. He only mentioned that he often gets less failures in his old environment than in the new one (by the new one he refers to RPM/YUM with gcc 4.9.2 I suppose). But this doesn't even mean that ln is involved here. Nor does it mean that ln shouldn't be used per se if some tests fail (it would mean, however, that I'd have to fix tests before asking for my patch to be accepted. And if anybody gives me any evidence that FATE tests fail because of *my* patch, I will fix it — when I have some spare time.) BTW, maybe aren't you thinking that FATE is not a part of FFmpeg development ? It of course is. See above. Because it just does just what is already doing well, without any benefits. Not true. I named you the benefits. And you still can't give me at least one real problem of using ln instead of cp. In addition, I suggested that you check if ln -s works really before overriding ln_s, however you did not. I don't have to do it because FFmpeg already works well even if without it. I asked you to do so because it's you who needs this in the first place and who can test it in the environment that does not support symlinks. My environment supports them so it's rather problematic to check. And also this is what I call collaboration. BTW, when I work with your patches to the projects that I maintain as a committer, I discuss it with you and if you refuse to modify something in your patch because you don't care, I simply do it myself and I give you credit for your work. I expect something similar from you at least. I don't understand what you are saying. You disabled those DLL creations in this patch, didn't you ? If you checked my patch and makefiles closer before arguing you would understand me. There are two places where versioned DLLs are created: the library build stage and the install stage. For the install stage it was enough to remove a couple of variables. But the build stage always first links avcodeXX.dll and then calls ln_s on it to create avcodec.dll (via a separate target), this can't be altered via variables. If you use cp, you will get a dumb and broken library that will also be lxlite'd. If you use ln, the library will also be broken but it will at least not occupy any disk space and will not be lxlite'd. There is nobody who is less busy than you, here. If you don't modify this patch yourself, nobody will do that. And who cares about divergent downstream ? I do care about consistency, collaboration and prevention of artificial entropy growth. But if I'm the only one who cares, I assure you I feel perfectly fine maintaining our own BWW repositories and I also don't need my name to be listed in the maintainers file or among commiters. It's you who's sabotaging my work here without any particular reason besides your religious belief that symlinks is evil. And it's quite natural that in this situation I don't have any further wish to change my patch just to make your internal believer happy. What about "ups" and "downs", well, it's just a matter of viewport, please don't be so childish here. A question to maintainers with commit rights: please clarify, what should I do to have my patches applied? -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
Dmitriy Kuminov wrote: > On 2016-04-19 12:56:23 +, KO Myung-Hun said: > >> I don't understand why you insist on using symlink. Even if without it, >> current FFmpeg works well, maybe better in according to Dave. I don't >> know what is the benefit from using symlink. > > Likewise, I don't understand why you insist on not using symlink. Even > with it, current FFmpeg works well, maybe better in according to me. I > don't know what is the benefit from not using symlink. > > I wrote it just to show that my statement is as valid as yours. > No, it's not because ln_s overriding is already there. And there is just no need to replace it. >> And it is you who would be affecting other people due to a personal >> favor. > > I don't see how my "personal favor" differs from your "personal favor" > here. The fact that you and Dave share the same idea of not liking > symlinks doesn't make it less personal. You didn't present any real-life > case where using symlinks in FFmpeg develompent hurts. > Did you present any real-life cases where not using symlinks in FFmpeg development hurts ? However, Dave reported some failure cases due to removing ln_s overriding. BTW, maybe aren't you thinking that FATE is not a part of FFmpeg development ? >> I just don't feel to do support symlink on OS/2 because it has no >> additional benefits. In addition, symlink is not a must-feature, unlike >> python's virtualenv. > > You are not right, there are benefits. Symlinking a DLL is much faster > than copying it over and requires less disk space, after all (which is > somewhat essential for debug builds with a lot of HLL info, e.g. debug > avcode56.dll is 42 MB here). And it also won't be lxlite'd (which also > saves a bit of build time). Also, in FFmpeg 3.x symlinking is used to > bring src into the build tree which shortens source paths considerably. > All these are rather minor things, I agree, but your insistence in not > using symlinks has NO real benefits at all. > At least, it passes FATE in according to Dave. >> I doubt that refusing to write codes for unnecessary features is not >> collaborative. > > I doubt that you can ultimatively decide which feature is necessary and > which is not. > Because it just does just what is already doing well, without any benefits. In addition, I suggested that you check if ln -s works really before overriding ln_s, however you did not. I don't have to do it because FFmpeg already works well even if without it. >> Finally, ln_s part is not related to the other parts. Split this patch >> into ln_s part and others, and re-send newly versioned patches, please. > > Well, it has some relation to patch 2/3 because it allows to avoid > creating an unneeded copy of an (un-)versioned DLL. It could also be I don't understand what you are saying. You disabled those DLL creations in this patch, didn't you ? > separated but unfortunately I don't have any more time to work on these > patches (as it turns out - just to please you). You can modify it > yourself if you wish (and if you are fine with the fact that it will > keep our branches diverged) but please give me some credit in the commit > message if the essential part of my patch remains. > There is nobody who is less busy than you, here. If you don't modify this patch yourself, nobody will do that. And who cares about divergent downstream ? I think, we confirmed the opinion of each other. No more discussions are helpful. Nevertheless, if you want to discuss more, mail me privately. Thanks. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-19 12:56:23 +, KO Myung-Hun said: I don't understand why you insist on using symlink. Even if without it, current FFmpeg works well, maybe better in according to Dave. I don't know what is the benefit from using symlink. Likewise, I don't understand why you insist on not using symlink. Even with it, current FFmpeg works well, maybe better in according to me. I don't know what is the benefit from not using symlink. I wrote it just to show that my statement is as valid as yours. And it is you who would be affecting other people due to a personal favor. I don't see how my "personal favor" differs from your "personal favor" here. The fact that you and Dave share the same idea of not liking symlinks doesn't make it less personal. You didn't present any real-life case where using symlinks in FFmpeg develompent hurts. I just don't feel to do support symlink on OS/2 because it has no additional benefits. In addition, symlink is not a must-feature, unlike python's virtualenv. You are not right, there are benefits. Symlinking a DLL is much faster than copying it over and requires less disk space, after all (which is somewhat essential for debug builds with a lot of HLL info, e.g. debug avcode56.dll is 42 MB here). And it also won't be lxlite'd (which also saves a bit of build time). Also, in FFmpeg 3.x symlinking is used to bring src into the build tree which shortens source paths considerably. All these are rather minor things, I agree, but your insistence in not using symlinks has NO real benefits at all. I doubt that refusing to write codes for unnecessary features is not collaborative. I doubt that you can ultimatively decide which feature is necessary and which is not. Finally, ln_s part is not related to the other parts. Split this patch into ln_s part and others, and re-send newly versioned patches, please. Well, it has some relation to patch 2/3 because it allows to avoid creating an unneeded copy of an (un-)versioned DLL. It could also be separated but unfortunately I don't have any more time to work on these patches (as it turns out - just to please you). You can modify it yourself if you wish (and if you are fine with the fact that it will keep our branches diverged) but please give me some credit in the commit message if the essential part of my patch remains. -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-19 06:03:52 +, Dave Yeo said: The problem is that symlinks on OS/2 (unless using TVFS.IFS) are inherently fragile. It just takes one utility that is not aware of them to break things and not everything is linked against kLIBC. In FFmpegs case we use lxlite, which is a Pascal program and knows nothing of symlinks. lxlite works with executables and we can't use symlinks for executables anyway (because the kernel doesn't support them and won't be able to load such binaries). If lxlite encounters a symlink to a dll or an exe, it will simply skip it (becuase it will only see a text file) - and this is asbolutely fine and safe. So lxlite is not a problem. You also speak theoretically, like KOMH. In practice, I personally don't know a single problem that would come out of symlinks and require something non-trivial to solve it. And I do A LOT of stuff. I personally prefer to only use symlinks when needed, such as _virtualenv, and currently using my older environment can often pass all the FATE tests, whereas the new environment has more failures. As leaving it in doesn't hurt your use case anyways, my vote is to leave it in. I always use symlinks and have absolutely no problems with that. You use the RPM/YUM UNIXROOT environment too (IIRC) so you indirectly use them as well. I can assure you, you wouldn't see all the current OS/2 progress if we didn't switch to the Unix-based toolchain. And symlinks is part of it. So it's not about the number of votes, it's about progress and future. http://fate.ffmpeg.org/history.cgi?slot=x86.os2.446 http://fate.ffmpeg.org/history.cgi?slot=x86.os2.492 Regarding tests, that's a different story. I believe symlinks have a tiny contribution in test failures (if at all). And that's in general, again. In case of FFmpeg, symlinks don't make any harm (at least you didn't present any proof of that so far). -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
Hi/2. Dmitriy Kuminov wrote: > On 2016-04-18 11:52:15 +, KO Myung-Hun said: > >> Strange conclusion. Anyway not important. > > In Dave's case the symlink functionality check fails because it is > performed in TMPDIR which is located on ramfs.ifs (which fails to use > symlinks). But I believe his real build directory is not on ramfs.ifs > and symlinks are in fact supported there (and can be used). But this > problem is not OS/2-specific, it may happen on any platform where TMPDIR > is on a volume that doesn't support symlinks for sojme reason. I think > the FFmpeg guys should fix this check to make it performed inside the > build directory, not in TMPDIR. > >> Good to know that. I wish to see the latest bash for OS/2 soon. > > Well, in fact, having bash would be not bad indeed, but since it has > little impact on end users, this is postponed for later. Your > contribution is (as always) welcome. > >> I meant those who don't use ln at all for compatibility with other OS/2 >> programs not built with kLIBC, like me. > > Okay, but still. I don't think ongoing OS/2 development should be > chained by people like you :) (nothing personal, of course). For > instance, you won't be able to build the latest Firefox if your system > doesn't support symlinks (at least because of python's virtualenv). And > I'm not going to invest time in making it work in such a case, not at > all (it's a pure waste). This is clearly offtopic for this mailing list > though, so let's continue this conversation in private if you want. > >> My "correction" is not removing ln_s overriding. I don't want to use ln >> -s on OS/2. > > Sorry but I really doubt things affecting other people should happen or > not happen just because you want it or not. We are all here to > collaborate. I added what I needed and what I think is the best. You > don't agree, that's OK, so I offered you a compromise - write your own > patch that will make it work for you the way you want it w/o breaking > what I need. You refuse to do so and I don't find it collaborative. It's > upto FFmpeg maintainers to decide what to do here, but I won't accept > symlink usage removal in our repositiries. I will, however, accept your > patch that will allow to go both ways (with the symlink usage being the > default choice if supported by the underlying IFS). > I don't understand why you insist on using symlink. Even if without it, current FFmpeg works well, maybe better in according to Dave. I don't know what is the benefit from using symlink. And it is you who would be affecting other people due to a personal favor. I just don't feel to do support symlink on OS/2 because it has no additional benefits. In addition, symlink is not a must-feature, unlike python's virtualenv. I doubt that refusing to write codes for unnecessary features is not collaborative. Finally, ln_s part is not related to the other parts. Split this patch into ln_s part and others, and re-send newly versioned patches, please. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 04/16/16 11:00 AM, Dmitriy Kuminov wrote: On 2016-04-16 17:24:12 +, Dave Yeo said: Actually I now get this at the beginning of the configure run, using a ramfs.ifs volume for $TMPDIR, [K:\usr\local\src\ffmpeg.obj]sh ../ffmpeg/configure --enable-gpl --disable-doc --samples=/usr/local/share/fate-suite --cpu=i686 --extra-libs=-lpoll --prefix='r:/tmp/ffmpeg' --disable-static --enable-shared ln: failed to create symbolic link `R:/tmp/name_VJhuEZNf': Operation not supported on socket Hmm, interesting use case. I bet this is because ramfs.ifs has some problems with EAs (which are needed for proper symlink support on OS/2). Looks like a ramfs.ifs bug to me. While ramfs.ifs has a few shortcomings, it dies support 64kbs of EAs, which shouldbe enough for most uses. Perhaps the problem is lack of DosFindNotify() or file locking. And yes, it seems that the master branch uses ln_s not only in DLL creation but also to symlink to src in the shadow build tree (I was checking against the 2.8 branch before where it was not used). It, however, contains a fallback code that should cover the failure in your case (if I read it right). So I still think we should remove ln_s redefinition via cp on OS/2 in FFmpeg. In case of a proper IFS (I have JFS here but HPFS is also fine) symlinking src works like a charm (performed a full build). The problem is that symlinks on OS/2 (unless using TVFS.IFS) are inherently fragile. It just takes one utility that is not aware of them to break things and not everything is linked against kLIBC. In FFmpegs case we use lxlite, which is a Pascal program and knows nothing of symlinks. I personally prefer to only use symlinks when needed, such as _virtualenv, and currently using my older environment can often pass all the FATE tests, whereas the new environment has more failures. As leaving it in doesn't hurt your use case anyways, my vote is to leave it in. Dave http://fate.ffmpeg.org/history.cgi?slot=x86.os2.446 http://fate.ffmpeg.org/history.cgi?slot=x86.os2.492 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-18 11:52:15 +, KO Myung-Hun said: Strange conclusion. Anyway not important. In Dave's case the symlink functionality check fails because it is performed in TMPDIR which is located on ramfs.ifs (which fails to use symlinks). But I believe his real build directory is not on ramfs.ifs and symlinks are in fact supported there (and can be used). But this problem is not OS/2-specific, it may happen on any platform where TMPDIR is on a volume that doesn't support symlinks for sojme reason. I think the FFmpeg guys should fix this check to make it performed inside the build directory, not in TMPDIR. Good to know that. I wish to see the latest bash for OS/2 soon. Well, in fact, having bash would be not bad indeed, but since it has little impact on end users, this is postponed for later. Your contribution is (as always) welcome. I meant those who don't use ln at all for compatibility with other OS/2 programs not built with kLIBC, like me. Okay, but still. I don't think ongoing OS/2 development should be chained by people like you :) (nothing personal, of course). For instance, you won't be able to build the latest Firefox if your system doesn't support symlinks (at least because of python's virtualenv). And I'm not going to invest time in making it work in such a case, not at all (it's a pure waste). This is clearly offtopic for this mailing list though, so let's continue this conversation in private if you want. My "correction" is not removing ln_s overriding. I don't want to use ln -s on OS/2. Sorry but I really doubt things affecting other people should happen or not happen just because you want it or not. We are all here to collaborate. I added what I needed and what I think is the best. You don't agree, that's OK, so I offered you a compromise - write your own patch that will make it work for you the way you want it w/o breaking what I need. You refuse to do so and I don't find it collaborative. It's upto FFmpeg maintainers to decide what to do here, but I won't accept symlink usage removal in our repositiries. I will, however, accept your patch that will allow to go both ways (with the symlink usage being the default choice if supported by the underlying IFS). -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
Dmitriy Kuminov wrote: > On 2016-04-17 05:21:31 +, KO Myung-Hun said: > >> Even if it's a bug of ramfs.ifs, its bug should be considered when using >> ln -s. > > Yes, and in this particular case configure handles it safely. It results > into a false fallback though because the symlink dir check is performed > in TMPDIR which in fact may be on a different FS than the directory used > for the shadow build. But this is a bug in configure not related to OS/2 > at all. > Strange conclusion. Anyway not important. >> However, some shells such as bash and pdksh using EMX does not support a >> symbolic link. > > This is a valid point per se. But I believe there is little sense in > putting any afforts to support some dead software from 90s for which we > have a better and somewhat supported alternative. Both bash and pdksh > can be rebuilt with kLIBC if really needed (not top priprity for BWW atm > as there are much more improtant things to do). > Good to know that. I wish to see the latest bash for OS/2 soon. >> In addition, there are people not using ln -s for >> compatibility. So if possible, it would be better to avoid a symbolic >> link. > > Well some people may still use FAT with OS/2 for compatibility. I don't > think ongoing development should be chained by them... > I meant those who don't use ln at all for compatibility with other OS/2 programs not built with kLIBC, like me. >> Anyway, test if ln -s really works and override ln_s if it fails. > > To that I agree, it's the best solution. Can you provide your correction > to this patch that prefrorms such a check in the "os/2" case at least? I > guess you use EMX bash/pdksh so you can test it right away. > My "correction" is not removing ln_s overriding. I don't want to use ln -s on OS/2. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-17 05:21:31 +, KO Myung-Hun said: Even if it's a bug of ramfs.ifs, its bug should be considered when using ln -s. Yes, and in this particular case configure handles it safely. It results into a false fallback though because the symlink dir check is performed in TMPDIR which in fact may be on a different FS than the directory used for the shadow build. But this is a bug in configure not related to OS/2 at all. However, some shells such as bash and pdksh using EMX does not support a symbolic link. This is a valid point per se. But I believe there is little sense in putting any afforts to support some dead software from 90s for which we have a better and somewhat supported alternative. Both bash and pdksh can be rebuilt with kLIBC if really needed (not top priprity for BWW atm as there are much more improtant things to do). In addition, there are people not using ln -s for compatibility. So if possible, it would be better to avoid a symbolic link. Well some people may still use FAT with OS/2 for compatibility. I don't think ongoing development should be chained by them... Anyway, test if ln -s really works and override ln_s if it fails. To that I agree, it's the best solution. Can you provide your correction to this patch that prefrorms such a check in the "os/2" case at least? I guess you use EMX bash/pdksh so you can test it right away. -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
Dmitriy Kuminov wrote: > On 2016-04-16 17:24:12 +, Dave Yeo said: > >> Actually I now get this at the beginning of the configure run, using a >> ramfs.ifs volume for $TMPDIR, >> >> [K:\usr\local\src\ffmpeg.obj]sh ../ffmpeg/configure --enable-gpl >> --disable-doc --samples=/usr/local/share/fate-suite --cpu=i686 >> --extra-libs=-lpoll --prefix='r:/tmp/ffmpeg' --disable-static >> --enable-shared >> ln: failed to create symbolic link `R:/tmp/name_VJhuEZNf': Operation not >> supported on socket > > Hmm, interesting use case. I bet this is because ramfs.ifs has some > problems with EAs (which are needed for proper symlink support on OS/2). > Looks like a ramfs.ifs bug to me. > Even if it's a bug of ramfs.ifs, its bug should be considered when using ln -s. > And yes, it seems that the master branch uses ln_s not only in DLL > creation but also to symlink to src in the shadow build tree (I was > checking against the 2.8 branch before where it was not used). It, > however, contains a fallback code that should cover the failure in your > case (if I read it right). So I still think we should remove ln_s > redefinition via cp on OS/2 in FFmpeg. In case of a proper IFS (I have > JFS here but HPFS is also fine) symlinking src works like a charm > (performed a full build). > However, some shells such as bash and pdksh using EMX does not support a symbolic link. In addition, there are people not using ln -s for compatibility. So if possible, it would be better to avoid a symbolic link. Anyway, test if ln -s really works and override ln_s if it fails. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-16 17:24:12 +, Dave Yeo said: Actually I now get this at the beginning of the configure run, using a ramfs.ifs volume for $TMPDIR, [K:\usr\local\src\ffmpeg.obj]sh ../ffmpeg/configure --enable-gpl --disable-doc --samples=/usr/local/share/fate-suite --cpu=i686 --extra-libs=-lpoll --prefix='r:/tmp/ffmpeg' --disable-static --enable-shared ln: failed to create symbolic link `R:/tmp/name_VJhuEZNf': Operation not supported on socket Hmm, interesting use case. I bet this is because ramfs.ifs has some problems with EAs (which are needed for proper symlink support on OS/2). Looks like a ramfs.ifs bug to me. And yes, it seems that the master branch uses ln_s not only in DLL creation but also to symlink to src in the shadow build tree (I was checking against the 2.8 branch before where it was not used). It, however, contains a fallback code that should cover the failure in your case (if I read it right). So I still think we should remove ln_s redefinition via cp on OS/2 in FFmpeg. In case of a proper IFS (I have JFS here but HPFS is also fine) symlinking src works like a charm (performed a full build). -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 04/16/16 09:29 AM, Dmitriy Kuminov wrote: On 2016-04-16 04:52:23 +, KO Myung-Hun said: diff --git a/configure b/configure index ff80aee..36a23f4 100755 --- a/configure +++ b/configure @@ -4716,7 +4716,6 @@ case $target_os in ;; os/2*) strip="lxlite -CS" -ln_s="cp -f" Please do not remove this. Copying is more compatible than a symbolic link on OS/2. "More compatible" is a too general allegation. In this particular case (FFmpeg) LN_S is only used to create 'avcodec.dll` from `avcode56.dll` and alike which is completely unneeded on OS/2 (so symlinking doesn't harm but saves some time & disk space). And more over, symlinks work well in most cases in a proper OS/2 environment these days. So I think they should be generally enabled unless there is a specific case when they introduce a real incompatibility. FFmpeg is not such a case. Actually I now get this at the beginning of the configure run, using a ramfs.ifs volume for $TMPDIR, [K:\usr\local\src\ffmpeg.obj]sh ../ffmpeg/configure --enable-gpl --disable-doc --samples=/usr/local/share/fate-suite --cpu=i686 --extra-libs=-lpoll --prefix='r:/tmp/ffmpeg' --disable-static --enable-shared ln: failed to create symbolic link `R:/tmp/name_VJhuEZNf': Operation not supported on socket I'll have to file a bug at Netlabs Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 2016-04-16 04:52:23 +, KO Myung-Hun said: diff --git a/configure b/configure index ff80aee..36a23f4 100755 --- a/configure +++ b/configure @@ -4716,7 +4716,6 @@ case $target_os in ;; os/2*) strip="lxlite -CS" -ln_s="cp -f" Please do not remove this. Copying is more compatible than a symbolic link on OS/2. "More compatible" is a too general allegation. In this particular case (FFmpeg) LN_S is only used to create 'avcodec.dll` from `avcode56.dll` and alike which is completely unneeded on OS/2 (so symlinking doesn't harm but saves some time & disk space). And more over, symlinks work well in most cases in a proper OS/2 environment these days. So I think they should be generally enabled unless there is a specific case when they introduce a real incompatibility. FFmpeg is not such a case. -- Kind regards, Dmitriy Kuminov CPO of bww bitwise works GmbH ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
Hi/2. Dave Yeo wrote: > On 04/14/16 07:29 PM, Dave Yeo wrote: >>> From fbff28a583cc9fd7144dd4f9dc37b7b5f8aa Mon Sep 17 00:00:00 2001 >> From: Dmitriy Kuminov >> Date: Thu, 14 Apr 2016 01:45:01 +0400 >> Subject: [PATCH 2/3] configure: Do not create/install versioned DLLs on >> OS/2. > > Attached > Dave> From fbff28a583cc9fd7144dd4f9dc37b7b5f8aa Mon Sep 17 00:00:00 2001 > From: Dmitriy Kuminov > Date: Thu, 14 Apr 2016 01:45:01 +0400 > Subject: [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2. > > Only one DLL for each module must be present on OS/2: SLIBNAME_WITH_MAJOR > (the same as on Windows). Creating other DLLs makes no sense as they can't > be used. > > Signed-off-by: Dave Yeo > --- > configure | 23 --- > 1 file changed, 12 insertions(+), 11 deletions(-) > > diff --git a/configure b/configure > index ff80aee..36a23f4 100755 > --- a/configure > +++ b/configure > @@ -4716,7 +4716,6 @@ case $target_os in > ;; > os/2*) > strip="lxlite -CS" > -ln_s="cp -f" Please do not remove this. Copying is more compatible than a symbolic link on OS/2. > objformat="aout" > add_cppflags -D_GNU_SOURCE > add_ldflags -Zomf -Zbin-files -Zargs-wild -Zmap > @@ -4724,16 +4723,18 @@ case $target_os in > LIBSUF="_s.a" > SLIBPREF="" > SLIBSUF=".dll" > -SLIBNAME_WITH_VERSION='$(SLIBPREF)$(NAME)-$(LIBVERSION)$(SLIBSUF)' > -SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(shell echo $(NAME) | cut > -c1-6)$(LIBMAJOR)$(SLIBSUF)' > -SLIB_CREATE_DEF_CMD='echo LIBRARY $(SLIBNAME_WITH_MAJOR) > INITINSTANCE TERMINSTANCE > $(SUBDIR)$(NAME).def; \ > -echo CODE PRELOAD MOVEABLE DISCARDABLE >> $(SUBDIR)$(NAME).def; \ > -echo DATA PRELOAD MOVEABLE MULTIPLE NONSHARED >> > $(SUBDIR)$(NAME).def; \ > -echo EXPORTS >> $(SUBDIR)$(NAME).def; \ > -emxexp $(OBJS) >> $(SUBDIR)$(NAME).def' > -SLIB_EXTRA_CMD='emximp -o $(SUBDIR)$(LIBPREF)$(NAME)_dll.a > $(SUBDIR)$(NAME).def; \ > -emximp -o $(SUBDIR)$(LIBPREF)$(NAME)_dll.lib > $(SUBDIR)$(NAME).def;' > -SLIB_INSTALL_EXTRA_LIB='$(LIBPREF)$(NAME)_dll.a > $(LIBPREF)$(NAME)_dll.lib' > + > SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)' > +SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(shell echo $(FULLNAME) | cut > -c1-6)$(LIBMAJOR)$(SLIBSUF)' > +SLIB_CREATE_DEF_CMD='echo LIBRARY $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=) > INITINSTANCE TERMINSTANCE > $(SUBDIR)$(FULLNAME).def; \ > +echo CODE PRELOAD MOVEABLE DISCARDABLE >> > $(SUBDIR)$(FULLNAME).def; \ > +echo DATA PRELOAD MOVEABLE MULTIPLE NONSHARED >> > $(SUBDIR)$(FULLNAME).def; \ > +echo EXPORTS >> $(SUBDIR)$(FULLNAME).def; \ > +emxexp $(OBJS) >> $(SUBDIR)$(FULLNAME).def' > +SLIB_EXTRA_CMD='emximp -o $(SUBDIR)$(LIBPREF)$(FULLNAME)_dll.a > $(SUBDIR)$(FULLNAME).def; \ > +emximp -o $(SUBDIR)$(LIBPREF)$(FULLNAME)_dll.lib > $(SUBDIR)$(FULLNAME).def;' > +SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)' > +SLIB_INSTALL_LINKS= > +SLIB_INSTALL_EXTRA_LIB='$(LIBPREF)$(FULLNAME)_dll.a > $(LIBPREF)$(FULLNAME)_dll.lib' > enable dos_paths > enable_weak os2threads > ;; > -- > 2.0.0 > > > -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On 04/14/16 07:29 PM, Dave Yeo wrote: From fbff28a583cc9fd7144dd4f9dc37b7b5f8aa Mon Sep 17 00:00:00 2001 From: Dmitriy Kuminov Date: Thu, 14 Apr 2016 01:45:01 +0400 Subject: [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2. Attached Dave From fbff28a583cc9fd7144dd4f9dc37b7b5f8aa Mon Sep 17 00:00:00 2001 From: Dmitriy Kuminov Date: Thu, 14 Apr 2016 01:45:01 +0400 Subject: [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2. Only one DLL for each module must be present on OS/2: SLIBNAME_WITH_MAJOR (the same as on Windows). Creating other DLLs makes no sense as they can't be used. Signed-off-by: Dave Yeo --- configure | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/configure b/configure index ff80aee..36a23f4 100755 --- a/configure +++ b/configure @@ -4716,7 +4716,6 @@ case $target_os in ;; os/2*) strip="lxlite -CS" -ln_s="cp -f" objformat="aout" add_cppflags -D_GNU_SOURCE add_ldflags -Zomf -Zbin-files -Zargs-wild -Zmap @@ -4724,16 +4723,18 @@ case $target_os in LIBSUF="_s.a" SLIBPREF="" SLIBSUF=".dll" -SLIBNAME_WITH_VERSION='$(SLIBPREF)$(NAME)-$(LIBVERSION)$(SLIBSUF)' -SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(shell echo $(NAME) | cut -c1-6)$(LIBMAJOR)$(SLIBSUF)' -SLIB_CREATE_DEF_CMD='echo LIBRARY $(SLIBNAME_WITH_MAJOR) INITINSTANCE TERMINSTANCE > $(SUBDIR)$(NAME).def; \ -echo CODE PRELOAD MOVEABLE DISCARDABLE >> $(SUBDIR)$(NAME).def; \ -echo DATA PRELOAD MOVEABLE MULTIPLE NONSHARED >> $(SUBDIR)$(NAME).def; \ -echo EXPORTS >> $(SUBDIR)$(NAME).def; \ -emxexp $(OBJS) >> $(SUBDIR)$(NAME).def' -SLIB_EXTRA_CMD='emximp -o $(SUBDIR)$(LIBPREF)$(NAME)_dll.a $(SUBDIR)$(NAME).def; \ -emximp -o $(SUBDIR)$(LIBPREF)$(NAME)_dll.lib $(SUBDIR)$(NAME).def;' -SLIB_INSTALL_EXTRA_LIB='$(LIBPREF)$(NAME)_dll.a $(LIBPREF)$(NAME)_dll.lib' +SLIBNAME_WITH_VERSION='$(SLIBPREF)$(FULLNAME)-$(LIBVERSION)$(SLIBSUF)' +SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(shell echo $(FULLNAME) | cut -c1-6)$(LIBMAJOR)$(SLIBSUF)' +SLIB_CREATE_DEF_CMD='echo LIBRARY $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=) INITINSTANCE TERMINSTANCE > $(SUBDIR)$(FULLNAME).def; \ +echo CODE PRELOAD MOVEABLE DISCARDABLE >> $(SUBDIR)$(FULLNAME).def; \ +echo DATA PRELOAD MOVEABLE MULTIPLE NONSHARED >> $(SUBDIR)$(FULLNAME).def; \ +echo EXPORTS >> $(SUBDIR)$(FULLNAME).def; \ +emxexp $(OBJS) >> $(SUBDIR)$(FULLNAME).def' +SLIB_EXTRA_CMD='emximp -o $(SUBDIR)$(LIBPREF)$(FULLNAME)_dll.a $(SUBDIR)$(FULLNAME).def; \ +emximp -o $(SUBDIR)$(LIBPREF)$(FULLNAME)_dll.lib $(SUBDIR)$(FULLNAME).def;' +SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)' +SLIB_INSTALL_LINKS= +SLIB_INSTALL_EXTRA_LIB='$(LIBPREF)$(FULLNAME)_dll.a $(LIBPREF)$(FULLNAME)_dll.lib' enable dos_paths enable_weak os2threads ;; -- 2.0.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.
On Thu, Apr 14, 2016 at 07:29:26PM -0700, Dave Yeo wrote: > >From fbff28a583cc9fd7144dd4f9dc37b7b5f8aa Mon Sep 17 00:00:00 2001 > From: Dmitriy Kuminov > Date: Thu, 14 Apr 2016 01:45:01 +0400 > Subject: [PATCH 2/3] configure: Do not create/install versioned DLLs > on OS/2. > > Only one DLL for each module must be present on OS/2: SLIBNAME_WITH_MAJOR > (the same as on Windows). Creating other DLLs makes no sense as they can't > be used. > > Signed-off-by: Dave Yeo > --- > configure | 23 --- > 1 file changed, 12 insertions(+), 11 deletions(-) > > diff --git a/configure b/configure > index ff80aee..36a23f4 100755 > --- a/configure > +++ b/configure > @@ -4716,7 +4716,6 @@ case $target_os in > ;; > os/2*) > strip="lxlite -CS" > -ln_s="cp -f" > objformat="aout" > add_cppflags -D_GNU_SOURCE > add_ldflags -Zomf -Zbin-files -Zargs-wild -Zmap > @@ -4724,16 +4723,18 @@ case $target_os in > LIBSUF="_s.a" > SLIBPREF="" > SLIBSUF=".dll" > -SLIBNAME_WITH_VERSION='$(SLIBPREF)$(NAME)-$(LIBVERSION)$(SLIBSUF)' > -SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(shell echo $(NAME) | cut > -c1-6)$(LIBMAJOR)$(SLIBSUF)' > -SLIB_CREATE_DEF_CMD='echo LIBRARY $(SLIBNAME_WITH_MAJOR) > INITINSTANCE TERMINSTANCE > $(SUBDIR)$(NAME).def; \ > -echo CODE PRELOAD MOVEABLE DISCARDABLE >> > $(SUBDIR)$(NAME).def; \ > -echo DATA PRELOAD MOVEABLE MULTIPLE NONSHARED >> > $(SUBDIR)$(NAME).def; \ > -echo EXPORTS >> $(SUBDIR)$(NAME).def; \ this patch has been corrupted with linebreaks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel