configure.ac in Tesseract 3.03 r997
87 views
Skip to first unread message
AK
Jan 20, 2014, 7:41:10 AM1/20/14
to tesser...@googlegroups.com
Line 11 in configure.ac, r997 reads
CXXFLAGS=""
This causes problems if you try to pass CXXFLAGS to configure via the command line. In my case I was passing in the flags "-O0 -g3" for debugging purposes.
This little issue caused me to waste most of my day today - admittedly someone with better knowledge of shell scripting/Autotools/what-not would not have been stymied by this little problem to the extent I was, and I did learn a few new things in the process, but regardless... this was not how I would've liked to have spent my day! (Sorry, just blowing off some steam.)
CXXFLAGS=""
This causes problems if you try to pass CXXFLAGS to configure via the command line. In my case I was passing in the flags "-O0 -g3" for debugging purposes.
This little issue caused me to waste most of my day today - admittedly someone with better knowledge of shell scripting/Autotools/what-not would not have been stymied by this little problem to the extent I was, and I did learn a few new things in the process, but regardless... this was not how I would've liked to have spent my day! (Sorry, just blowing off some steam.)
zdenko podobny
Jan 20, 2014, 7:47:01 AM1/20/14
to tesser...@googlegroups.com
Why you did not use --enable-debug ;-)?
But you are right there should be better solution than CXXFLAGS=""...
Zdenko
--
You received this message because you are subscribed to the Google Groups "tesseract-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tesseract-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
AK
Jan 20, 2014, 1:23:13 PM1/20/14
to tesser...@googlegroups.com
Zdenko,
Don't get me started on --enable-debug, my friend! :/
On Mac OS X 10.9 with the default toolchain, the -O2 optimization level (due to --enable-debug) appears to be too aggressive - or at least that's how I understand it. Breakpoints often get missed. (Thanks goes out to a developer by the name of Maxim for helping me with that).
Akiel
Don't get me started on --enable-debug, my friend! :/
On Mac OS X 10.9 with the default toolchain, the -O2 optimization level (due to --enable-debug) appears to be too aggressive - or at least that's how I understand it. Breakpoints often get missed. (Thanks goes out to a developer by the name of Maxim for helping me with that).
Akiel
zdenko podobny
Jan 20, 2014, 4:35:31 PM1/20/14
to tesser...@googlegroups.com
- How did you try to pass the flags '-O0 -g3'?
- Can you please try to replace 'CXXFLAGS=""' with'${CXXFLAGS=""}' if it solve you problem?
Zdenko
AK
Jan 21, 2014, 12:23:06 AM1/21/14
to tesser...@googlegroups.com
Sorry, I guess I wasn't clear in my original rant: I'd already solved the problem (for myself at least) by getting rid off the the line CXXFLAGS="" altogether.
Is the line CXXFLAGS="" needed at all in configure.ac? I think this variable is getting created somewhere else (like CFLAGS - and we don't have a corresponding CFLAGS="" in configure.ac). The line wasn't there at all in several previous versions of tesseract, except the r996 - where it was ${CXXFLAGS=""} which you mentioned in your post. The problem with ${CXXFLAGS=""} is that the script tries to execute it as a command.
Googling shows that this works: CXXFLAGS=${CXXFLAGS:-""}
It will create CXXFLAGS (initialized to ""} if it doesn't exist, or if it exists (such as if I pass it via the command line) keep the same value.
Is the line CXXFLAGS="" needed at all in configure.ac? I think this variable is getting created somewhere else (like CFLAGS - and we don't have a corresponding CFLAGS="" in configure.ac). The line wasn't there at all in several previous versions of tesseract, except the r996 - where it was ${CXXFLAGS=""} which you mentioned in your post. The problem with ${CXXFLAGS=""} is that the script tries to execute it as a command.
Googling shows that this works: CXXFLAGS=${CXXFLAGS:-""}
It will create CXXFLAGS (initialized to ""} if it doesn't exist, or if it exists (such as if I pass it via the command line) keep the same value.
Tom Morris
Jan 21, 2014, 1:28:30 AM1/21/14
to tesser...@googlegroups.com
On Tue, Jan 21, 2014 at 12:23 AM, AK <aki...@gmail.com> wrote:
Sorry, I guess I wasn't clear in my original rant: I'd already solved the problem (for myself at least)
Googling shows that this works: CXXFLAGS=${CXXFLAGS:-""}
So, if you had a proposed solution, is there a reason you didn't offer it? Perhaps even in the form of an easy-to-apply patch?
Tom
AK
Jan 21, 2014, 1:55:27 AM1/21/14
to tesser...@googlegroups.com
It's because I don't want to break anything unless/until I have a good idea of what I'm doing - which I don't.
As I mentioned, I don't really understand why there was suddenly a need to initialize CXXFLAGS to a null string in configure.ac, something not done in previous releases, and if that is indeed needed for some reason, even though my proposed solution CXXFLAGS=${CXXFLAGS:-""} seems to solve the problem I was having, I don't know if it'll create incompabilities for someone using a different shell flavour or configuration or whatever.
As a case in point, the person who applied the previous "patch" - CXXFLAGS="" from r996 to ${CXXFLAGS:-""} in r997 in configure.ac - possibly did it to solve a problem he was having, but it ended up creating a problem for me, and I want to be careful before making the same mistake.
As I mentioned, I don't really understand why there was suddenly a need to initialize CXXFLAGS to a null string in configure.ac, something not done in previous releases, and if that is indeed needed for some reason, even though my proposed solution CXXFLAGS=${CXXFLAGS:-""} seems to solve the problem I was having, I don't know if it'll create incompabilities for someone using a different shell flavour or configuration or whatever.
As a case in point, the person who applied the previous "patch" - CXXFLAGS="" from r996 to ${CXXFLAGS:-""} in r997 in configure.ac - possibly did it to solve a problem he was having, but it ended up creating a problem for me, and I want to be careful before making the same mistake.
zdenko podobny
Jan 21, 2014, 2:46:41 AM1/21/14
to tesser...@googlegroups.com
Let me write you some background for this issue ;-):
During my tests I found out that system (openSUSE 13.1) always add its default option ('-g -O2') "to the end" and my my settings ('-g -Wall -Wno-uninitialized -O0 -DDEBUG' were before it.
According gcc "Options That Control Optimization" page[1]: "If you use multiple -O options, with or without level numbers, the last such option is the one that is effective." This means that my -O0 was ignored... I looked at possible solutions and after several test I found out solution in ${CXXFLAGS=""} - this was implemented in r906.
Last week I started to test mingw build on windows (to build training app for windows users), but there was problem with '${CXXFLAGS=""}' and CXXFLAGS="" seems to fix it. Yesterday I made test on linux and it looks like I need to revert this change (I will put back '${CXXFLAGS=""}') and I need to find some other solution for mingw only...
For me it is important to know that '${CXXFLAGS=""} works (e.g. it eliminate system defaults and you define you custom option).
Anyway for debugging I suggest to use --enable-debug. Have a look at code to see its options[3].
Zdenko
--
AK
Jan 21, 2014, 4:41:10 AM1/21/14
to tesser...@googlegroups.com
Zdenko,
LIke I said previously, I assumed that whoever (as it turns out, you) did the modification with the configure.ac file probably had a strong reason to do so - and obviously it's not possible for anyone to perfectly anticipate how a change is going to effect every possible use scenario on every possible system. It's admirable that Tesseract can run on so many different platforms and environments, but yeah, it doesn't come without headaches. I think we (or at least I) need to understand the build system better in order to use it properly.
The problem you mentioned with the openSUSE system (flags -g -O2 being appended) has been occurring on my system (OS X 10.9) too, ever since I started using Tesseract 3.02 (stable version) a month or so ago: when I said in my earlier post, "On Mac OS X 10.9 with the default toolchain, the -O2 optimization level (due to --enable-debug) appears to be too aggressive".
I was mistakenly blaming --enable-debug for setting the flags to "-g -O2". The actual problem was the one you pointed out, with the flags "-g -O2" being appended and overriding the flags set by --enable-debug).
Anyway, my solution to this problem had been to set CXXFLAGS explicitly through the command-line, and it was working until you noticed the same problem on openSUSE and tried a different solution for it, causing my solution to break - that's how I comprehend the situation.
Coming to your proposed solution itself, i.e. adding the line ${CXXFLAGS=""} in configure.ac:
What happens on OpenSuse when you run the configure script with the line ${CXXFLAGS=""}? On my OS X 10.9 system the first line that configure spits out on the screen is:
./configure: line 2506: : command not found
and a quick check shoes that "line 2506" in configure is in fact: ${CXXFLAGS=""}
so it appears that a side-effect of this method is the script tries to run CXXFLAGS (containing the empty string "") as an executable. Presumably no one has a command called CXXFLAGS on their path(!) so nothing is going to happen, but overall this does not seem to be a good thing to have happen.
Perhaps you should consider the solution I mentioned in my previous post:
CXXFLAGS=${CXXFLAGS:-""}
This lets the user override CXXFLAGS (assuming he knows what he's doing) while setting it to "" if he doesn't. And it doesn't cause CXXFLAGS to be executed.
---
I have read in some places that CXXFLAGS shouldn't be messed with in the build scripts because these flags are meant for the users and overriding them in the scripts can cause surprises of the bad kind (as in my case). Presumably the idea is that the user should know what they're doing (which evidently isn't always the case, taking myself as an example! - but I'm trying to learn). But then again, I do not really know why CXXFLAGS defaults to "-g -O2" on some systems (it's probably a convention or standard) and what the proper way is to deal with flag conflicts as in the case of --enable-debug.
I don't want to waste too much of your time on this issue (I know I have). but this discussion about making a debug target is interesting:
http://stackoverflow.com/questions/4553735/gnu-autotools-debug-release-targets
The accepted answer is similar to your approach, but (given my limited understanding) I'm inclined to agree with the the second answer (which is more highly voted), i.e. I feel that let the user (who wants to debug) pass in manually the appropriate flags themselves, instead of offering an --enable-debug option at all. But at the very least we need a more robust solution that avoids unexpected surprises and at least issues some warnings when conflicting flags are passed.
LIke I said previously, I assumed that whoever (as it turns out, you) did the modification with the configure.ac file probably had a strong reason to do so - and obviously it's not possible for anyone to perfectly anticipate how a change is going to effect every possible use scenario on every possible system. It's admirable that Tesseract can run on so many different platforms and environments, but yeah, it doesn't come without headaches. I think we (or at least I) need to understand the build system better in order to use it properly.
The problem you mentioned with the openSUSE system (flags -g -O2 being appended) has been occurring on my system (OS X 10.9) too, ever since I started using Tesseract 3.02 (stable version) a month or so ago: when I said in my earlier post, "On Mac OS X 10.9 with the default toolchain, the -O2 optimization level (due to --enable-debug) appears to be too aggressive".
I was mistakenly blaming --enable-debug for setting the flags to "-g -O2". The actual problem was the one you pointed out, with the flags "-g -O2" being appended and overriding the flags set by --enable-debug).
Anyway, my solution to this problem had been to set CXXFLAGS explicitly through the command-line, and it was working until you noticed the same problem on openSUSE and tried a different solution for it, causing my solution to break - that's how I comprehend the situation.
Coming to your proposed solution itself, i.e. adding the line ${CXXFLAGS=""} in configure.ac:
What happens on OpenSuse when you run the configure script with the line ${CXXFLAGS=""}? On my OS X 10.9 system the first line that configure spits out on the screen is:
./configure: line 2506: : command not found
and a quick check shoes that "line 2506" in configure is in fact: ${CXXFLAGS=""}
so it appears that a side-effect of this method is the script tries to run CXXFLAGS (containing the empty string "") as an executable. Presumably no one has a command called CXXFLAGS on their path(!) so nothing is going to happen, but overall this does not seem to be a good thing to have happen.
Perhaps you should consider the solution I mentioned in my previous post:
CXXFLAGS=${CXXFLAGS:-""}
This lets the user override CXXFLAGS (assuming he knows what he's doing) while setting it to "" if he doesn't. And it doesn't cause CXXFLAGS to be executed.
---
I have read in some places that CXXFLAGS shouldn't be messed with in the build scripts because these flags are meant for the users and overriding them in the scripts can cause surprises of the bad kind (as in my case). Presumably the idea is that the user should know what they're doing (which evidently isn't always the case, taking myself as an example! - but I'm trying to learn). But then again, I do not really know why CXXFLAGS defaults to "-g -O2" on some systems (it's probably a convention or standard) and what the proper way is to deal with flag conflicts as in the case of --enable-debug.
I don't want to waste too much of your time on this issue (I know I have). but this discussion about making a debug target is interesting:
http://stackoverflow.com/questions/4553735/gnu-autotools-debug-release-targets
The accepted answer is similar to your approach, but (given my limited understanding) I'm inclined to agree with the the second answer (which is more highly voted), i.e. I feel that let the user (who wants to debug) pass in manually the appropriate flags themselves, instead of offering an --enable-debug option at all. But at the very least we need a more robust solution that avoids unexpected surprises and at least issues some warnings when conflicting flags are passed.
zdenko podobny
Jan 21, 2014, 4:24:45 PM1/21/14
to tesser...@googlegroups.com
Thanks! Tested in mingw and linux and CXXFLAGS=${CXXFLAGS:-""} solve the problem.
I will include it to my next patch, but current mingw32+msys is stubborn ;-)
Zdenko
Reply all
Reply to author
Forward
0 new messages