Re: [bug-gnu-libiconv] [PATCH] Append the extension to the executables properly

[KO Myung-Hun]

Hi/2.

Bruno Haible wrote:
> Hi Ko,
> 
> Reviving this discussion from 2016-12-16:
> 
>>> But now I found a README.os2 of some package which reads:
>>>
>>> -------------------------------------------------------------------------------
>>> Installation on OS/2:
>>>
>>> - Requires emx+gcc and a working shell (Bourne shell, Korn shell or GNU 
>>> bash).
>>>
>>> - Set the environment variables CC=gcc CFLAGS="-Zexe" before calling
>>>   `configure'.
>>> -------------------------------------------------------------------------------
>>>
>>> The documentation of the -Zexe option:
>>>
>>> -Zexe
>>>
>>>     If the -Zexe option is present, emxomfld deletes the output file
>>>     (whose name is given on the command line) and adds .exe to the
>>>     output filename.  After calling LINK386, emxomfld creates an empty
>>>     output file (without .exe).  This feature is used for minimizing
>>>     changes to Unixoid makefiles.  See also the -Zexe option of GCC
>>>     and ld.
>>>
>>> So it seems that neither your Makefile.in patch nor my 'os2compile' script
>>> is needed. Add you need is to set CFLAGS="-Zexe" before calling configure !!
>>>
>>
>> Although I don't know the package you are saying, adding -Zexe to CFLAGS
>> is not a good way. Of course, I also sometimes use -Zexe mainly for
>> testing build works before patching sources such as scripts and
>> Makefiles. However, I don't prefer -Zexe because:
>> 1. It cannot be used to build DLLs. On OS/2, -Zdll is used to build
>> DLLs. -Zexe and -Zdll cannot be used at the same time. In case of
>> libiconv, DLLs such as iconv2.dll cannot be built with CFLAGS="-Zexe" by
>> libtool using -Zdll.
>> 2. Currently, Makefile of libiconv tests requires ../src/iconv_no_i18n
>> as a dependency. However, its real target is ../src/iconv_no_i18n.exe on
>> OS/2.
>> 3. It generates both [file] and [file.exe]. Generally, however, Makefile
>> cleans only [file], so [file.exe] remains. This is not true for Makefile
>> of libiconv tests.
>>
>> Therefore, setting CFLAGS="-Zexe" and calling configure is not a proper
>> solution.
> 
> Later you said that LDFLAGS="-Zexe" instead of CFLAGS="-Zexe" would work.
> 

What I meant is that adding -Zexe to LDFLAGS is more proper than CFLAGS.

> Is the issue [1] remaining then?

Sure. It's linking problem. -Zexe and -Zdll cannot be used at the same time.

> [2] and [3] are not very disturbing if you use "make" only for building
> in batch mode; it's only when you are the main developer of a package that you
> care about these, right?
> 

Even if not the main developer, someone testing libiconv on OS/2 would
encounter the same problem.


>> In case of os2compile:
>> 1. This is slow, about 1.5 factor.
>> 2. This shares [2] and [3] of -Zexe problems.
>> 3. In addition, a target [file] will be generated whenever Makefile is
>> called. Because [file.exe] is genereated not [file].
> 
> These seem like acceptable compromises to me. Heck, when I run a 'configure'
> script in Cygwin, it runs with the same speed as a Linux machine 15-20 years
> ago. Speed does not matter much here.
> 

Ooops... configure speed on OS/2 seems to be faster than on Cygwin.
Anyway, it's too hard to endure slower configure speed because it's
already enough slow.

>> Moreover, @EXEEXT@ is already used in Makefile of libiconv tests.
> 
> Yes, and the few necessary uses already clutter up the Makefile.
> It's OK for Automake-generated Makefiles to use $(EXEEXT) all over the place,
> but in libiconv the Makefile.in is manually maintained, and clutter is not
> welcome here.
> 

Then @EXEEXT@ and $(EXEEXT) are not allowed any longer ?

-- 
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