Re: [libmicrohttpd] Build issue on MINGW

[Tim Rühsen]

Hi Christian,

tested --enable-experimental but then - guess what :-) - I need to 'make
install' which fails. So I'm back at checking out the latest release
tag. NP, I am just going to wait until the next release.

Regards, Tim

On 10/23/18 12:53 PM, Christian Grothoff wrote:
> Hi Tim,
> 
> Well, the --enable-experimental switch was already added to Git master
> when I sent the e-mail.  As for doing features in new branches, that is
> sometimes done, but in this case the specific goal was to expose the
> code to a broad range of build systems to see if there were any compile
> errors on some platforms -- intentionally long before putting the code
> near production, hence 'noinst' (and building it _last_, so even if it
> failed, the rest would just work). Still, I think the
> --enable-experimental flag is reasonable at this time.
> 
> Happy hacking!
> 
> Christian
> 
> On 10/23/2018 10:28 AM, Tim Rühsen wrote:
>> Hi Christian,
>>
>> sorry for answering so late :-(
>>
>> Such a switch would indeed be useful if one wants to test/use the latest
>> master branch.
>>
>> In my case it is using latest master as dependency for CI Testing of
>> Wget2. This includes a MinGW CI runner.
>>
>> Of course I can checkout the latest release tag, but atm I try to find
>> issues in MHD development early.
>>
>> There is also the possibility to slightly change the development cycle
>> of MHD:
>> - Add new a feature in an own branch
>> - Push that branch to Gitlab.com to test the code via CI (we already
>> created CI runners), optionally create an MR (merge request) for
>> discussion/collaboration.
>> - When CI succeeds: merging of the feature branch into master (directly
>> or via Gitlab UI)
>>
>> That way you keep the master branch clean and tested.
>>
>> Whatever you decide, let me know and I'll change my build scripts :-)
>>
>> Regards, Tim
>>
>>
>> On 10/18/18 5:34 PM, Christian Grothoff wrote:
>>> Hi Tim,
>>>
>>> The issue is that in line Makefile.am:10, we have "noinst_" instead of
>>> "lib_" because the code is far from complete and it must not yet be
>>> installed. That causes the dlname='' issue you describe.
>>>
>>> The best fix I can propose: I'm adding an option (--enable-experimental)
>>> which disables building src/lib/ by default, so that users that don't
>>> care about the experimental code don't get disrupted like this.
>>>
>>> Happy hacking!
>>>
>>> Christian
>>>
>>> On 10/18/2018 04:45 PM, Tim Rühsen wrote:
>>>> Hi,
>>>>
>>>> the build on MinGW fails in lib/src/ due to
>>>>
>>>>         @echo Creating $@ and libmicrohttpd2.exp by $(DLLTOOL)... && \
>>>>         dll_name=`$(EGREP) -o dlname=\'.+\' libmicrohttpd2.la` && \
>>>>
>>>> libmicrohttpd2.la contains
>>>>   dlname=''
>>>> and thus the egrep (or grep -E) fails.
>>>>
>>>> I am on Debian unstable and use this sequence in a script:
>>>>
>>>> unset CC
>>>> PREFIX=x86_64-w64-mingw32
>>>> export INSTALLDIR="$PWD/$PREFIX"
>>>> export PKG_CONFIG_PATH=$INSTALLDIR/lib/pkgconfig
>>>> export CPPFLAGS="-I$INSTALLDIR/include"
>>>> export LDFLAGS="-L$INSTALLDIR/lib"
>>>> export CFLAGS="-O2 -Wall -Wno-format"
>>>>
>>>> git clone --recursive https://github.com/dlfcn-win32/dlfcn-win32.git
>>>> cd dlfcn-win32
>>>> ./configure --prefix=$PREFIX --cc=$PREFIX-gcc
>>>> make
>>>> cp -p libdl.a ../$PREFIX/lib/
>>>> cp -p dlfcn.h ../$PREFIX/include/
>>>> cd ..
>>>>
>>>> git clone --recursive https://gnunet.org/git/libmicrohttpd.git
>>>> cd libmicrohttpd
>>>> ./bootstrap
>>>> ./configure --build=x86_64-pc-linux-gnu --host=$PREFIX
>>>> --prefix=$INSTALLDIR --disable-doc --disable-examples --enable-shared
>>>> make clean
>>>> make -j$(nproc)
>>>> cd ..
>>>>
>>>>
>>>> Regards, Tim
>>>>
>>

signature.asc
Description: OpenPGP digital signature