Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.

2016-04-27 Thread Michael Niedermayer 
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.

2016-04-27 Thread Dave Yeo 

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

Re: [FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.

2016-04-27 Thread Michael Niedermayer 
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.

2016-04-26 Thread Dmitriy Kuminov 

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.

2016-04-26 Thread KO Myung-Hun 


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.

2016-04-26 Thread Dave Yeo 

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.

2016-04-24 Thread Michael Niedermayer 
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.

2016-04-24 Thread Dave Yeo 

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.

2016-04-23 Thread Michael Niedermayer 
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.

2016-04-22 Thread Dmitriy Kuminov 

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.

2016-04-21 Thread Dave Yeo 

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.

2016-04-20 Thread Michael Niedermayer 
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.

2016-04-20 Thread Dmitriy Kuminov 

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.

2016-04-19 Thread Dmitriy Kuminov 

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.

2016-04-19 Thread Dmitriy Kuminov 

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.

2016-04-19 Thread KO Myung-Hun 
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.

2016-04-19 Thread Dave Yeo 

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.

2016-04-18 Thread Dmitriy Kuminov 

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.

2016-04-18 Thread KO Myung-Hun 


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.

2016-04-17 Thread Dmitriy Kuminov 

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.

2016-04-16 Thread KO Myung-Hun 


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.

2016-04-16 Thread Dmitriy Kuminov 

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.

2016-04-16 Thread Dave Yeo 

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.

2016-04-16 Thread Dmitriy Kuminov 

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.

2016-04-15 Thread KO Myung-Hun 
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.

2016-04-15 Thread Dave Yeo 

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.

2016-04-15 Thread Michael Niedermayer 
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