GCC-4.3 with 'mktime(3)'

[randy@…]

There's an issue with the build of bash and gawk in both Chapter 5 and Chapter 6 due to a glitch in GCC. The autoconf macro in both affected packages which searches for a system-installed mktime(3) function will fail, which causes the packages to build and use an internal mktime function.

Notes about it here: ​http://www.diy-linux.org/pipermail/diy-linux-dev/2008-February/001200.html

I suggest we add the ac_cv_func_working_mktime=yes hack to the configure command in both Chapters of both affected packages.

[bdubbs@…]

Is this necessary? What is the advantage of using a system installed mktime function for these packages instead of the internal version? The module that is included is 425 lines of source, including comments and preprocessor statements -- that's pretty small.

I recommend closing as wontfix.

[randy@…]

Replying to bdubbs@linuxfromscratch.org:

I recommend closing as wontfix.

Well I disagree simply because it is a bug. GCC introduced this regression and there's a simple (a few typed characters) fix for it.

It may be an upstream problem, but at least we're identifying it and providing a solution.

As far as what advantage it is, I can't say. But let me turn your question around Bruce and ask you: What disadvantage is it to use a system function that the packages look for before using an internal copy?

Furthermore, the behavior has *changed*, These packages have always used the system copy in the past, so this effectively is changing our build method (as minute as it may be) if we don't provide the 'fix'.

And lastly, it causes the package build to 'hang up' for a while before timing out and proceeding.

Just my thoughts.

[bdubbs@…]

Replying to randy@linuxfromscratch.org:

Replying to bdubbs@linuxfromscratch.org:

I recommend closing as wontfix.

Well I disagree simply because it is a bug. GCC introduced this regression and there's a simple (a few typed characters) fix for it.

I do not think that it is a 'bug'. It is a change where gawk and bash have not caught up. Checking my logs, findutils, coreutils, and tar find mktime just fine.

It may be an upstream problem, but at least we're identifying it and providing a solution.

I do not disagree.

As far as what advantage it is, I can't say. But let me turn your question around Bruce and ask you: What disadvantage is it to use a system function that the packages look for before using an internal copy?

My thought process was that it will probably be fixed in the next gawk and bash releases. Then we will need to change the book back. I didn't see any particular advantage or disadvantage for either method.

Furthermore, the behavior has *changed*, These packages have always used the system copy in the past, so this effectively is changing our build method (as minute as it may be) if we don't provide the 'fix'.

Personally, I don't think this matters.

And lastly, it causes the package build to 'hang up' for a while before timing out and proceeding.

OK. A test shows a delay of 0.4 SBU on my system for just that delay. Do you want to make the change or shall I?

[randy@…]

Replying to bdubbs@linuxfromscratch.org:

OK. A test shows a delay of 0.4 SBU on my system for just that delay. Do you want to make the change or shall I?

Doesn't matter. Go ahead. I've got plenty of other tickets that I need to address.

[bdubbs@…]

Fixed in revision 8690.