[ragel-users] [PATCH 0/3] Fix Cygwin build

Tue Nov 27 11:09:01 UTC 2018

OK, that's good that I can forget about --with-ragel.  As to how -no-undefined 
works, I've done some googling and still don't fully understand it.  I see the 
-no-undefined flag passed to libtool but then it doesn't appear in the final 
link command:

/bin/sh ../libtool  --tag=CXX   --mode=link g++  -Wall -g -no-undefined...

libtool: link: g++ -shared -nostdlib 
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/crtbeginS.o  .libs/libfsm_la-idbase.o 
.libs/libfsm_la-fsmstate.o .libs/libfsm_la-fsmbase.o .libs/libfsm_la-fsmattach.o 
.libs/libfsm_la-fsmmin.o .libs/libfsm_la-fsmgraph.o .libs/libfsm_la-fsmap.o 
.libs/libfsm_la-fsmcond.o .libs/libfsm_la-fsmnfa.o .libs/libfsm_la-common.o 
.libs/libfsm_la-redfsm.o .libs/libfsm_la-gendata.o .libs/libfsm_la-allocgen.o 
.libs/libfsm_la-codegen.o .libs/libfsm_la-actexp.o .libs/libfsm_la-binvar.o 
.libs/libfsm_la-tables.o .libs/libfsm_la-tabgoto.o .libs/libfsm_la-tabvar.o 
.libs/libfsm_la-binary.o .libs/libfsm_la-bingoto.o .libs/libfsm_la-actloop.o 
.libs/libfsm_la-flat.o .libs/libfsm_la-flatgoto.o .libs/libfsm_la-flatvar.o 
.libs/libfsm_la-goto.o .libs/libfsm_la-gotoloop.o .libs/libfsm_la-gotoexp.o 
.libs/libfsm_la-ipgoto.o .libs/libfsm_la-dot.o .libs/libfsm_la-asm.o 
-L/home/kbrown/src/colm/src -L/usr/lib/gcc/x86_64-pc-cygwin/7.3.0 
-L/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/lib/../lib 
-L/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../lib -L/lib/../lib 
-L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/lib 
-L/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../.. -lstdc++ -lgcc_s -lgcc -lcygwin 
-ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc 
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/crtend.o  -g   -o .libs/cygfsm-0.dll 
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libfsm.dll.a

I think the point might be that gcc/g++ will give errors on Cygwin if there are 
undefined symbols in shared libraries, and libtool enforces that by insisting on 
the -no-undefined flag, which is simply an assertion that there are no undefined 
symbols.  That's mostly a guess.

I have the same automake, autoconf, and libtool versions as you, but a newer gcc 
(7.3.0).

Ken

On 11/27/2018 5:49 AM, Adrian Thurston wrote:
> First, the easy part ... you can take out --with-ragel and --with-kelbt options. 
> They were only there to fall back to during the transition to the colm frontend. 
> I've committed to the colm parser though and will be removing the old one soon.
> 
> With regards to linking, it has no effect for me when I used -no-undefined. 
> Seems to get stripped out by autotools because it doesn't make it into the link 
> command.
> 
> libragel_la_LDFLAGS = -no-undefined
> 
> ... results in ...
> 
> libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
> /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o 
> /usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o .libs/libragel_la-parsetree.o 
> .libs/libragel_la-longest.o .libs/libragel_la-parsedata.o 
> .libs/libragel_la-inputdata.o .libs/libragel_la-load.o 
> .libs/libragel_la-reducer.o   -Wl,-rpath 
> -Wl,/home/thurston/devel/ragel/src/.libs -Wl,-rpath 
> -Wl,/home/thurston/pkgs/colm/lib -Wl,-rpath -Wl,/home/thurston/pkgs/ragel/lib 
> -Wl,-rpath -Wl,/home/thurston/pkgs/colm/lib -L/home/thurston/pkgs/colm/lib 
> ./.libs/libfsm.so /home/thurston/pkgs/colm/lib/libcolm.so 
> -L/usr/lib/gcc/x86_64-linux-gnu/5 
> -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu 
> -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu 
> -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
> -L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. -lstdc++ -lm -lc -lgcc_s 
> /usr/lib/gcc/x86_64-linux-gnu/5/crtendS.o 
> /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o  -g -Wl,-soname 
> -Wl,libragel.so.0 -o .libs/libragel.so.0.0.0
> 
> My setup is ubuntu with the following versions.
> 
> [thurston at railay] src: g++ -v; automake --version; autoconf --version; libtool 
> --version
> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
> automake (GNU automake) 1.15
> autoconf (GNU Autoconf) 2.69
> libtool (GNU libtool) 2.4.6
> 
> Will have to dig a bit. Maybe the option is controlled by some other flag.
> 
> On 2018-11-26 16:30, Ken Brown wrote:
>> Thanks.  There are still two problems:
>>
>> First, the syntax for the libtool '-no-undefined' flag is wrong.  It should
>> simply be '-no-undefined' (one leading hyphen, no -Wl), as in the patch I
>> submitted.  Otherwise, I get the following error if I try to build
>> shared libraries:
>>
>> libtool:   error: can't build x86_64-unknown-cygwin shared library unless
>> -no-undefined is specified
>>
>> Second, although your change takes care of the reference to rl_parse, which is
>> the only undefined reference in a build --without-ragel, there are two further
>> "undefined reference" errors if I build with ragel installed:
>>
>> .libs/libragel_la-inputdata.o: In function
>> `InputData::checkLastRef(InputItem*)':
>> /home/kbrown/src/ragel/src/inputdata.cc:313: undefined reference to
>> `Parser6::terminateParser()'
>> [...]
>> .libs/libragel_la-inputdata.o: In function `InputData::parseKelbt()':
>> /home/kbrown/src/ragel/src/inputdata.cc:427: undefined reference to
>> `Scanner::do_scan()'
>>
>> These are defined in rlparse.cc and rlscan.cc, which aren't in the sources for
>> libragel.
>>
>> Ken
>>
>> On 11/26/2018 11:40 AM, Adrian Thurston wrote:
>>> Ah, sorry, I forgot to push from my private repo to the public one. There now.
>>>
>>> On 2018-11-25 12:11, Ken Brown wrote:
>>>> Hi Adrian,
>>>>
>>>> Thanks.  Have you pushed these changes to the upstream git repo?  I'm getting
>>>> "Already up to date" when I do "git pull".
>>>>
>>>> Ken
>>>>
>>>> On 11/25/2018 8:22 AM, Adrian Thurston wrote:
>>>>> Hi Ken, thank you for the patches. I just enabled --no-undefined and 
>>>>> removed the
>>>>> reference to the undefined symbol. The parse.c file cannot be included in
>>>>> libragel because it defines the frontnend language, which is different for 
>>>>> each
>>>>> binary in the host-* directories. All that was needed was to pass the 
>>>>> reference
>>>>> to rl_parse into libragel from main.cc. Was already doing that for the backend
>>>>> code generator (also a colm program).
>>>>>
>>>>> Adrian
>>>>>
>>>>> On 2018-11-16 16:58, Ken Brown wrote:
>>>>>> I've just built ragel-7.0.0.11 on Cygwin and added it to the Cygwin
>>>>>> distribution.  I had to patch the sources in order to build shared
>>>>>> libraries.
>>>>>>
>>>>>> libtool won't build shared libraries on Cygwin unless the
>>>>>> -no-undefined flag is given.  The first patch of this series does that
>>>>>> for libfsm and libragel.  But it turns out that there are in fact
>>>>>> undefined symbols in libragel.  The next two patches fix that.
>>>>>>
>>>>>> I don't think these patches do any harm on other platforms.
>>>>>>
>>>>>> Ken Brown (3):
>>>>>>   add -no-undefined to LDFLAGS for libfsm and libragel
>>>>>>   add dependency of libragel on libfsm and libcolm
>>>>>>   avoid undefined symbols in libragel
>>>>>>
>>>>>>  src/Makefile.am | 20 ++++++++++++++------
>>>>>>  1 file changed, 14 insertions(+), 6 deletions(-)
>>>>>
>>>>> _______________________________________________
>>>>> ragel-users mailing list
>>>>> ragel-users at colm.net
>>>>> http://www.colm.net/cgi-bin/mailman/listinfo/ragel-users
>>>> _______________________________________________
>>>> ragel-users mailing list
>>>> ragel-users at colm.net
>>>> http://www.colm.net/cgi-bin/mailman/listinfo/ragel-users
>>>
>>> _______________________________________________
>>> ragel-users mailing list
>>> ragel-users at colm.net
>>> http://www.colm.net/cgi-bin/mailman/listinfo/ragel-users
>> _______________________________________________
>> ragel-users mailing list
>> ragel-users at colm.net
>> http://www.colm.net/cgi-bin/mailman/listinfo/ragel-users
> 
> 
> _______________________________________________
> ragel-users mailing list
> ragel-users at colm.net
> http://www.colm.net/cgi-bin/mailman/listinfo/ragel-users