[ragel-users] [PATCH 0/3] Fix Cygwin build
Adrian Thurston
thurston at colm.net
Wed Nov 28 09:15:59 UTC 2018
Ok, I guess we check for cygwin and use the appropriate option. I don't
normally build on cygwin so I would like to enforce it on linux as well.
On 2018-11-28 00:03, Ken Brown wrote:
> This seems to confirm my interpretation of "-no-undefined":
>
> $ libtool --help --mode=link | grep -- -no-undefined
> -no-undefined declare that a library does not refer to external
> symbols
>
> Ken
>
> On 11/27/2018 11:09 AM, Ken Brown wrote:
>> 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
>> _______________________________________________
>> 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
More information about the ragel-users
mailing list