flex-devel

[Flex-devel] Status of the patch for bug 182?

[Damian R. <da...@so...>]

Hi All,

I’m new to flex and only have a need to install it because it is required for building GCC from source (https://gcc.gnu.org/install/prerequisites.html).  My flex build on OS fails for the same reason as the December 2014 bug report 182 (http://sourceforge.net/p/flex/bugs/182/), which contains a patch that Bastien Chevreux confirmed works on 18 October 2015. Could someone please let me know the status of the submitted patch?  Will this patch or another one that fixes the problem be applied to your repository and released soon?  

FYI, I’m supporting OS X users of OpenCoarrays (https://github.com/sourceryinstitute/opencoarrays), for which a recent build of GCC is a requirement.  I’ve written a script that can install all of our prerequisites, but the script currently fails on OS X because of the aforementioned bug.  I’d very much like to avoid having to apply this patch in the script, especially because of the potential for the patch to become out-of-date over time.

Also, the priority on the bug shows as 5.  Is that a high priority or a low priority?  If it’s low, is there any chance of someone bumping the status up?  The submitted patch is approaching one year old.

Damian

Re: [Flex-devel] Status of the patch for bug 182?

[Will E. <wes...@gm...>]

On Monday,  9 November 2015,  7:25 am -0800, Damian Rouson <da...@so...> wrote:

> Hi All,
> 
> I’m new to flex and only have a need to install it because it is required for building GCC from source (https://gcc.gnu.org/install/prerequisites.html).  My flex build on OS fails for the same reason as the December 2014 bug report 182 (http://sourceforge.net/p/flex/bugs/182/), which contains a patch that Bastien Chevreux confirmed works on 18 October 2015. Could someone please let me know the status of the submitted patch?  Will this patch 
It's in the queue. I'm just gearing back up to get flex some time, so things will start moving again.

or another one that fixes the problem be applied to your repository and released soon?  

That is the plan, yes.

> 
> FYI, I’m supporting OS X users of OpenCoarrays (https://github.com/sourceryinstitute/opencoarrays), for which a recent build of GCC is a requirement.  I’ve written a script that can install all of our prerequisites, but the script currently fails on OS X because of the aforementioned bug.  I’d very much like to avoid having to apply this patch in the script, especially because of the potential for the patch to become out-of-date over time.
> 
> Also, the priority on the bug shows as 5.  Is that a high priority or a low priority?  If it’s low, is there any chance of someone bumping the status up?  The submitted patch is approaching one year old.

That's the default medium priority assigned by sourceforge. I'll move this one up in the queue, though. Also note that there's a lot of work that has happened in flex's git tree that has not been released yet. I've got a handful of pull requests to work through in the next few days and I'll add #182 to that list as well. At that point I'll make a release.

Can you also verify that the proposed patch works for you on OSX? I don't have an OSX machine to test on and the symptom doesn't manifest on my linux box.



> 
> Damian
> ------------------------------------------------------------------------------
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a 
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
> _______________________________________________
> Flex-devel mailing list
> Fle...@li...
> https://lists.sourceforge.net/lists/listinfo/flex-devel

-- 
Will Estes
Flex Project Maintainer
wes...@gm...
https://github.com/westes/flex

Re: [Flex-devel] Status of the patch for bug 182?

[Will E. <wes...@gm...>]

Looks like you should be in src/ for that patch to apply.. So, from where you were:

$ cd src/
 $ patch < ../patchfile

As you can see from the lines that start with - and +, that patch is changing linker options (the *LDFLAGS variables in Makefile.am) for the libfl variants that get built. Apparently it needs the version info and since building this way was new to me, I likely copied whatever the manual said to do.

On Tuesday, 10 November 2015,  1:27 am -0800, Damian Rouson <da...@so...> wrote:

> 
> ________________________________
> Damian Rouson, Ph.D., P.E.
> President, Sourcery Institute
> http://www.sourceryinstitute.org
> +1-510-600-2992 (mobile)
> 
> > On Nov 9, 2015, at 7:41 AM, Will Estes <wes...@gm...> wrote:
> > 
> > That's the default medium priority assigned by sourceforge. I'll move this one up in the queue, though. Also note that there's a lot of work that has happened in flex's git tree that has not been released yet. I've got a handful of pull requests to work through in the next few days and I'll add #182 to that list as well. At that point I'll make a release.
> 
> Thanks for the update. 
> 
> > 
> > Can you also verify that the proposed patch works for you on OSX? I don't have an OSX machine to test on and the symptom doesn't manifest on my linux box.
> 
> 
> I’ve always had difficulty applying patches.  Here’s what the patch gives me, but I won’t be surprised if I’m doing something wrong:
> 
> localhost:flex-2.5.39 rouson$ cat file.patch
> --- Makefile.am copy    2014-10-27 16:41:46.000000000 +0900
> +++ Makefile.am 2014-10-27 16:48:56.000000000 +0900
> @@ -73,13 +73,13 @@
>     libmain.c \
>     libyywrap.c
> 
> -libfl_la_LDFLAGS = -no-undefined -version-info @SHARED_VERSION_INFO@
> +libfl_la_LDFLAGS = -version-info @SHARED_VERSION_INFO@
> 
>  libfl_pic_la_SOURCES = \
>     libmain.c \
>     libyywrap.c
> 
> -libfl_pic_la_LDFLAGS = -no-undefined -version-info @SHARED_VERSION_INFO@
> +libfl_pic_la_LDFLAGS = -version-info @SHARED_VERSION_INFO@
> 
>  noinst_HEADERS = \
>     flexdef.h \
> localhost:flex-2.5.39 rouson$ patch -p0 < file.patch 
> patching file Makefile.am
> Hunk #1 FAILED at 73.
> 1 out of 1 hunk FAILED -- saving rejects to file Makefile.am.re
> 
> If you can provide instructions about how to apply the patch, I’ll be glad to try again.
> 
> D

-- 
Will Estes
wes...@gm...