ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
LS
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
IMO comment should be enough.
LS
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
I am not telling you how to resolve this issue, but the argument is a bit weak.
Simo.
On 01/13/2014 04:46 PM, Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo, attached patch addresses ticket #2193 I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
I am not telling you how to resolve this issue, but the argument is a bit weak.
Simo.
I agree that it is a bit weak. It depends upon where you put the stake into the ground, I mean what is the most important thing for an interface. IMO the most important thing is for the interface to be clean and consistent and not espose any internals. The debug function spoils a perfect picture. On one hand it is not a public function of the API on the other side it needs to be there for the internals not to be seen outside the library. So where it belongs in the library or outside? Since I assume the the core principal is that "nothing knows about the internals of the library other than the library itself" then the debug function is a part of the library but is not included into the public header. It is a compromise but a conscious compromise. And this approach you observe in the code. You might agree or disagree since IMO this is a question of taste and style rather than anything else.
On Mon, 2014-01-13 at 17:59 -0500, Dmitri Pal wrote:
On 01/13/2014 04:46 PM, Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo, attached patch addresses ticket #2193 I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
I am not telling you how to resolve this issue, but the argument is a bit weak.
Simo.
I agree that it is a bit weak. It depends upon where you put the stake into the ground, I mean what is the most important thing for an interface. IMO the most important thing is for the interface to be clean and consistent and not espose any internals. The debug function spoils a perfect picture. On one hand it is not a public function of the API on the other side it needs to be there for the internals not to be seen outside the library. So where it belongs in the library or outside? Since I assume the the core principal is that "nothing knows about the internals of the library other than the library itself" then the debug function is a part of the library but is not included into the public header. It is a compromise but a conscious compromise. And this approach you observe in the code. You might agree or disagree since IMO this is a question of taste and style rather than anything else.
I do not have a strong opinion, but I have a question. Why not simply expose the debug function in the public header then ?
Simo.
On 01/13/2014 06:08 PM, Simo Sorce wrote:
On Mon, 2014-01-13 at 17:59 -0500, Dmitri Pal wrote:
On 01/13/2014 04:46 PM, Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo, attached patch addresses ticket #2193 I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
I am not telling you how to resolve this issue, but the argument is a bit weak.
Simo.
I agree that it is a bit weak. It depends upon where you put the stake into the ground, I mean what is the most important thing for an interface. IMO the most important thing is for the interface to be clean and consistent and not espose any internals. The debug function spoils a perfect picture. On one hand it is not a public function of the API on the other side it needs to be there for the internals not to be seen outside the library. So where it belongs in the library or outside? Since I assume the the core principal is that "nothing knows about the internals of the library other than the library itself" then the debug function is a part of the library but is not included into the public header. It is a compromise but a conscious compromise. And this approach you observe in the code. You might agree or disagree since IMO this is a question of taste and style rather than anything else.
I do not have a strong opinion, but I have a question. Why not simply expose the debug function in the public header then ?
May be... it just feels wrong. It puts ABI commitment where there should be none. Imagine next time I need to create a debug function that instead of printing output puts it into the buffer. I would have to add it too. And then I realize that I want to have it formatted differently so I would need to add parameter that specifies format and so on.
I do not have a strong opinion either way. How it is now is the most logical way for me. But it might not be the best one. May be we should define the rule via Style guide and stick to it. I do not have a problem with that.
Simo.
On Mon, 2014-01-13 at 18:30 -0500, Dmitri Pal wrote:
On 01/13/2014 06:08 PM, Simo Sorce wrote:
On Mon, 2014-01-13 at 17:59 -0500, Dmitri Pal wrote:
On 01/13/2014 04:46 PM, Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote: > ehlo, > attached patch addresses ticket #2193 > I have just a question about refarray/libref_array.sym There is > extern function ref_array_debug, which is not defined in public > header file (not exposed in public API), but it is used in > ref_array unit tests. It needs to be in global section because > linker with fail to find symbol. Should I add any comment to the > file libref_array.sym or does anyone better solution? If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
I am not telling you how to resolve this issue, but the argument is a bit weak.
Simo.
I agree that it is a bit weak. It depends upon where you put the stake into the ground, I mean what is the most important thing for an interface. IMO the most important thing is for the interface to be clean and consistent and not espose any internals. The debug function spoils a perfect picture. On one hand it is not a public function of the API on the other side it needs to be there for the internals not to be seen outside the library. So where it belongs in the library or outside? Since I assume the the core principal is that "nothing knows about the internals of the library other than the library itself" then the debug function is a part of the library but is not included into the public header. It is a compromise but a conscious compromise. And this approach you observe in the code. You might agree or disagree since IMO this is a question of taste and style rather than anything else.
I do not have a strong opinion, but I have a question. Why not simply expose the debug function in the public header then ?
May be... it just feels wrong. It puts ABI commitment where there should be none. Imagine next time I need to create a debug function that instead of printing output puts it into the buffer. I would have to add it too. And then I realize that I want to have it formatted differently so I would need to add parameter that specifies format and so on.
If you put the function in the library you are committing to the ABI anyway. If you do not want to commit to the ABI you must not put the function in the library.
I do not have a strong opinion either way. How it is now is the most logical way for me. But it might not be the best one. May be we should define the rule via Style guide and stick to it. I do not have a problem with that.
It think a compromise would be to create a tests.h or similar header from the library and a .o object you link into the tests, but it is not included in the public library.
Simo.
On 01/14/2014 09:01 AM, Simo Sorce wrote:
On Mon, 2014-01-13 at 18:30 -0500, Dmitri Pal wrote:
On 01/13/2014 06:08 PM, Simo Sorce wrote:
On Mon, 2014-01-13 at 17:59 -0500, Dmitri Pal wrote:
On 01/13/2014 04:46 PM, Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote: > On 01/13/2014 01:42 PM, Lukas Slebodnik wrote: >> ehlo, >> attached patch addresses ticket #2193 >> I have just a question about refarray/libref_array.sym There is >> extern function ref_array_debug, which is not defined in public >> header file (not exposed in public API), but it is used in >> ref_array unit tests. It needs to be in global section because >> linker with fail to find symbol. Should I add any comment to the >> file libref_array.sym or does anyone better solution? > If this isn't a public API and isn't used except by the unit test, it > should probably not be built as part of the library. It should > probably be part of the unit test. IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
I am not telling you how to resolve this issue, but the argument is a bit weak.
Simo.
I agree that it is a bit weak. It depends upon where you put the stake into the ground, I mean what is the most important thing for an interface. IMO the most important thing is for the interface to be clean and consistent and not espose any internals. The debug function spoils a perfect picture. On one hand it is not a public function of the API on the other side it needs to be there for the internals not to be seen outside the library. So where it belongs in the library or outside? Since I assume the the core principal is that "nothing knows about the internals of the library other than the library itself" then the debug function is a part of the library but is not included into the public header. It is a compromise but a conscious compromise. And this approach you observe in the code. You might agree or disagree since IMO this is a question of taste and style rather than anything else.
I do not have a strong opinion, but I have a question. Why not simply expose the debug function in the public header then ?
May be... it just feels wrong. It puts ABI commitment where there should be none. Imagine next time I need to create a debug function that instead of printing output puts it into the buffer. I would have to add it too. And then I realize that I want to have it formatted differently so I would need to add parameter that specifies format and so on.
If you put the function in the library you are committing to the ABI anyway. If you do not want to commit to the ABI you must not put the function in the library.
No this is not true. There are public functions that are mentioned in the public API and header file and private functions that are not there. There is no guarantee on the private functions ever. Because they are private. If you code to them it is your problem if your application gets broken. The fact that an entry point is a part of the library does not make it a part of the interface nor applies any ABI guarantees to it unless it is explicitly declared as such.
I do not have a strong opinion either way. How it is now is the most logical way for me. But it might not be the best one. May be we should define the rule via Style guide and stick to it. I do not have a problem with that.
It think a compromise would be to create a tests.h or similar header from the library and a .o object you link into the tests, but it is not included in the public library.
Simo.
On (13/01/14 16:46), Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
Static linking would work with unit test, but function ref_array_reset is also used in the file ini/ini_valueobj.c (I forgot to mention it in the 1st mail)
1065 #ifdef HAVE_TRACE 1066 1067 ref_array_debug(vo->raw_lines, 0); 1068 ref_array_debug(vo->raw_lengths, 1); 1069 #endif
LS
On 01/14/2014 01:46 PM, Lukas Slebodnik wrote:
On (13/01/14 16:46), Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo, attached patch addresses ticket #2193 I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
Static linking would work with unit test, but function ref_array_reset is also
you mean ref_array_debug, right?
used in the file ini/ini_valueobj.c (I forgot to mention it in the 1st mail)
1065 #ifdef HAVE_TRACE 1066 1067 ref_array_debug(vo->raw_lines, 0); 1068 ref_array_debug(vo->raw_lengths, 1); 1069 #endif
yes it is used in the other "debug" situation. This is exactly the situation that I mentioned in the other mail: "use private functions from the library at your own risk". I acknowledge the risk, this is why it is if-defed not just not called based on an if() statement.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On (14/01/14 19:37), Dmitri Pal wrote:
On 01/14/2014 01:46 PM, Lukas Slebodnik wrote:
On (13/01/14 16:46), Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo, attached patch addresses ticket #2193 I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
Static linking would work with unit test, but function ref_array_reset is also
you mean ref_array_debug, right?
Yes, I meant ref_array_debug. (copy&paste problem :-)
BTW. It is already exposed in libref_array.so bash$ objdump -T /usr/lib64/libref_array.so | grep ref_array_debug 0000000000001300 g DF .text 0000000000000176 Base ref_array_debug ^^^ g means global
used in the file ini/ini_valueobj.c (I forgot to mention it in the 1st mail)
1065 #ifdef HAVE_TRACE 1066 1067 ref_array_debug(vo->raw_lines, 0); 1068 ref_array_debug(vo->raw_lengths, 1); 1069 #endif
yes it is used in the other "debug" situation. This is exactly the situation that I mentioned in the other mail: "use private functions from the library at your own risk". I acknowledge the risk, this is why it is if-defed not just not called based on an if() statement.
LS
On 01/15/2014 02:37 AM, Lukas Slebodnik wrote:
On (14/01/14 19:37), Dmitri Pal wrote:
On 01/14/2014 01:46 PM, Lukas Slebodnik wrote:
On (13/01/14 16:46), Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote: > ehlo, > attached patch addresses ticket #2193 > I have just a question about refarray/libref_array.sym There is > extern function ref_array_debug, which is not defined in public > header file (not exposed in public API), but it is used in > ref_array unit tests. It needs to be in global section because > linker with fail to find symbol. Should I add any comment to the > file libref_array.sym or does anyone better solution? If this isn't a public API and isn't used except by the unit test, it should probably not be built as part of the library. It should probably be part of the unit test.
IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
Static linking would work with unit test, but function ref_array_reset is also
you mean ref_array_debug, right?
Yes, I meant ref_array_debug. (copy&paste problem :-)
BTW. It is already exposed in libref_array.so bash$ objdump -T /usr/lib64/libref_array.so | grep ref_array_debug 0000000000001300 g DF .text 0000000000000176 Base ref_array_debug ^^^ g means global
My assumption was always always that if the entry point is in public header, then it is public. If not it is not.
ref_array.h which defines public interface does not deliberately list this function as public thus whether it is global or not really does not matter. It not public.
2c.
used in the file ini/ini_valueobj.c (I forgot to mention it in the 1st mail)
1065 #ifdef HAVE_TRACE 1066 1067 ref_array_debug(vo->raw_lines, 0); 1068 ref_array_debug(vo->raw_lengths, 1); 1069 #endif
yes it is used in the other "debug" situation. This is exactly the situation that I mentioned in the other mail: "use private functions from the library at your own risk". I acknowledge the risk, this is why it is if-defed not just not called based on an if() statement.
LS _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On (15/01/14 14:57), Dmitri Pal wrote:
On 01/15/2014 02:37 AM, Lukas Slebodnik wrote:
On (14/01/14 19:37), Dmitri Pal wrote:
On 01/14/2014 01:46 PM, Lukas Slebodnik wrote:
On (13/01/14 16:46), Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote:
On 01/13/2014 02:53 PM, Stephen Gallagher wrote: > On 01/13/2014 01:42 PM, Lukas Slebodnik wrote: >> ehlo, >> attached patch addresses ticket #2193 >> I have just a question about refarray/libref_array.sym There is >> extern function ref_array_debug, which is not defined in public >> header file (not exposed in public API), but it is used in >> ref_array unit tests. It needs to be in global section because >> linker with fail to find symbol. Should I add any comment to the >> file libref_array.sym or does anyone better solution? > If this isn't a public API and isn't used except by the unit test, it > should probably not be built as part of the library. It should > probably be part of the unit test. IMO this is conceptually wrong. Unit test emulates external use of the library. Unit test uses only public header and not private headers if any. If we put debug function in the unit test we will expose internal of the library that should not be know outside. I always view unit tests as example of use. If we show that it is OK to include private headers people would include private headers and try to access internal structures directly.
Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
Putting it into a separate module is probably the cleanest solution but IMO too much overhead.
A separate shared object would be too much, but you can statically link the function in the unit tests.
Static linking would work with unit test, but function ref_array_reset is also
you mean ref_array_debug, right?
Yes, I meant ref_array_debug. (copy&paste problem :-)
BTW. It is already exposed in libref_array.so bash$ objdump -T /usr/lib64/libref_array.so | grep ref_array_debug 0000000000001300 g DF .text 0000000000000176 Base ref_array_debug ^^^ g means global
My assumption was always always that if the entry point is in public header, then it is public. If not it is not.
ref_array.h which defines public interface does not deliberately list this function as public thus whether it is global or not really does not matter. It not public.
2c.
Linker knows nothing about header file. It works only with object modules (*.o). By default, it can distinguish only according to modifier (static vs extern)
Another options is to use attribute visibility eg. __attribute__ ((visibility ("hidden"))); __attribute__ ((visibility ("default")));
We decided to use 3rd option: version script https://fedorahosted.org/sssd/ticket/2193 ftp://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html
LS
On 01/16/2014 04:30 AM, Lukas Slebodnik wrote:
On (15/01/14 14:57), Dmitri Pal wrote:
On 01/15/2014 02:37 AM, Lukas Slebodnik wrote:
On (14/01/14 19:37), Dmitri Pal wrote:
On 01/14/2014 01:46 PM, Lukas Slebodnik wrote:
On (13/01/14 16:46), Simo Sorce wrote:
On Mon, 2014-01-13 at 15:00 -0500, Dmitri Pal wrote: > On 01/13/2014 02:53 PM, Stephen Gallagher wrote: >> On 01/13/2014 01:42 PM, Lukas Slebodnik wrote: >>> ehlo, >>> attached patch addresses ticket #2193 >>> I have just a question about refarray/libref_array.sym There is >>> extern function ref_array_debug, which is not defined in public >>> header file (not exposed in public API), but it is used in >>> ref_array unit tests. It needs to be in global section because >>> linker with fail to find symbol. Should I add any comment to the >>> file libref_array.sym or does anyone better solution? >> If this isn't a public API and isn't used except by the unit test, it >> should probably not be built as part of the library. It should >> probably be part of the unit test. > IMO this is conceptually wrong. > Unit test emulates external use of the library. Unit test uses only > public header and not private headers if any. > If we put debug function in the unit test we will expose internal of the > library that should not be know outside. > I always view unit tests as example of use. If we show that it is OK to > include private headers people would include private headers and try to > access internal structures directly. Sorry but I see a few issues with this argument.
You say that unit tests only use the public API, the you proceed and use an undisclosed API that is not made available through the public header files ? Isn't this contradictory ?
Also I see nothing wrong in accessing private data via unit tests, I never heard anyone have the expectation that unit tests are actually examples to follow.
> Putting it into a separate module is probably the cleanest solution but > IMO too much overhead. A separate shared object would be too much, but you can statically link the function in the unit tests.
Static linking would work with unit test, but function ref_array_reset is also
you mean ref_array_debug, right?
Yes, I meant ref_array_debug. (copy&paste problem :-)
BTW. It is already exposed in libref_array.so bash$ objdump -T /usr/lib64/libref_array.so | grep ref_array_debug 0000000000001300 g DF .text 0000000000000176 Base ref_array_debug ^^^ g means global
My assumption was always always that if the entry point is in public header, then it is public. If not it is not.
ref_array.h which defines public interface does not deliberately list this function as public thus whether it is global or not really does not matter. It not public.
2c.
Linker knows nothing about header file. It works only with object modules (*.o). By default, it can distinguish only according to modifier (static vs extern)
Another options is to use attribute visibility eg. __attribute__ ((visibility ("hidden"))); __attribute__ ((visibility ("default")));
We decided to use 3rd option: version script https://fedorahosted.org/sssd/ticket/2193 ftp://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html
LS
This is why I do not like the whole idea.
On (13/01/14 19:42), Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
LS
I forgot to include files into lib..._SOURCES, they was not part of dist tarball. Updated patch is attached.
I would like to know what we want to do with function ref_array_debug.
LS
On (16/01/14 10:17), Lukas Slebodnik wrote:
On (13/01/14 19:42), Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
LS
I forgot to include files into lib..._SOURCES, they was not part of dist tarball. Updated patch is attached.
I would like to know what we want to do with function ref_array_debug.
LS
The previous patch cannot be applied on ding-libs master due to conflict in Makefile.am
Rebased version is attached.
LS
On (21/02/14 10:54), Lukas Slebodnik wrote:
On (16/01/14 10:17), Lukas Slebodnik wrote:
On (13/01/14 19:42), Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
LS
I forgot to include files into lib..._SOURCES, they was not part of dist tarball. Updated patch is attached.
I would like to know what we want to do with function ref_array_debug.
LS
The previous patch cannot be applied on ding-libs master due to conflict in Makefile.am
Rebased version is attached.
LS
and now with correctly resolved problems after rebase. Is should have tested patch before sending mail.
LS
On (21/02/14 11:21), Lukas Slebodnik wrote:
On (21/02/14 10:54), Lukas Slebodnik wrote:
On (16/01/14 10:17), Lukas Slebodnik wrote:
On (13/01/14 19:42), Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
LS
I forgot to include files into lib..._SOURCES, they was not part of dist tarball. Updated patch is attached.
I would like to know what we want to do with function ref_array_debug.
LS
The previous patch cannot be applied on ding-libs master due to conflict in Makefile.am
Rebased version is attached.
LS
and now with correctly resolved problems after rebase. Is should have tested patch before sending mail.
LS
Replying to the different thread.
You started this discussion about version dependency in ding-libs. There is opportunity to be active and help us with testing and reviewing patch. https://lists.fedorahosted.org/pipermail/sssd-devel/2014-February/018553.htm...
Any comments are appreciated.
Certainly. [That mail has not hit the downloadable .gz archives yet and there is no git branch for it, so building the package on my side will be delayed./ The non-gz mailman archive has tabs replaced by spaces.] Comments without building thus:
The .sym files should be listed in Makefile.am in a _DEPENDENCIES line instead of _SOURCES. When they are in _SOURCES, `touch *.sym && make` won't relink the library, when they are in _DEPENDENCIES, they will:
libpath_utils_la_SOURCES = path_utils/path_utils.c libpath_utils_la_DEPENDENCIES = path_utils/libpath_utils.sym
Nice catch
The sym file will be part of `make dist` as before without having it to list in _SOURCES.
It did't work, but it is not a problem.
+LIBBASICOBJECTS_0.1.0 { +global:
- simplebuffer_free;
- ...
+local:
- *;
+};
+LIBBASICOBJECTS_0.1.1 { +global:
- simplebuffer_get_vbuf;
+} LIBBASICOBJECTS_0.1.0;
Since this is the initial presence of symvers in the library, there is not specifically a need to have more than one symbol: there exists no program out there that already references the LIBBASICOBJECTS_0.1.0 symbol, so you can just put all symbols under _0.1.1. This also applies to all the other .sym files.
It was not necessary to write symvers in this way. I wanted to write reference implementation of version symbol file. So, it would be easy to extend symvers in the future even for beginners.
Referring to libini_config for this next example:
The symbol name is connected to the library, so it does not need to try to be unique across the entire system AFAICS. If you like you can make it shorter, for example "ABI_4 { ... }" to point out that these functions were added in version 4 (cf. libtool number in -version-info). Or V_4. Whichever :)
This is true. I checked installed libraries on my desktop and it seems to be unwritten rule to use uppercased name of library for this purpose. Some libraries contain also string LIB in this identifier e.g libidn.so.11 (LIBIDN_1.0), libxml2.so.2(LIBXML2_2.4.30) libvirt.so.0(LIBVIRT_0.0.3), libsystemd-daemon.so.0(LIBSYSTEMD_DAEMON_31) Other libraries ommit string LIB from identifier e.g libsolv.so.0(SOLV_1.0), libtevent.so.0(TEVENT_0.9.9) libgcrypt.so.11(GCRYPT_1.2), libnss3.so(NSS_3.2)
Only two libraries from package setools-libs use identifier VERS_4.1 e.g libseaudit.so.4, libapol.so.4
The biggest group uses upperace identifier without string LIB. I decided to remove "prefix" LIB.
Updated patch is attached
Thank you very much for your comments.
LS
On (25/02/14 20:02), Lukas Slebodnik wrote:
On (21/02/14 11:21), Lukas Slebodnik wrote:
On (21/02/14 10:54), Lukas Slebodnik wrote:
On (16/01/14 10:17), Lukas Slebodnik wrote:
On (13/01/14 19:42), Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
LS
I forgot to include files into lib..._SOURCES, they was not part of dist tarball. Updated patch is attached.
I would like to know what we want to do with function ref_array_debug.
LS
The previous patch cannot be applied on ding-libs master due to conflict in Makefile.am
Rebased version is attached.
LS
and now with correctly resolved problems after rebase. Is should have tested patch before sending mail.
LS
Replying to the different thread.
You started this discussion about version dependency in ding-libs. There is opportunity to be active and help us with testing and reviewing patch. https://lists.fedorahosted.org/pipermail/sssd-devel/2014-February/018553.htm...
Any comments are appreciated.
Certainly. [That mail has not hit the downloadable .gz archives yet and there is no git branch for it, so building the package on my side will be delayed./ The non-gz mailman archive has tabs replaced by spaces.] Comments without building thus:
The .sym files should be listed in Makefile.am in a _DEPENDENCIES line instead of _SOURCES. When they are in _SOURCES, `touch *.sym && make` won't relink the library, when they are in _DEPENDENCIES, they will:
libpath_utils_la_SOURCES = path_utils/path_utils.c libpath_utils_la_DEPENDENCIES = path_utils/libpath_utils.sym
Nice catch
The sym file will be part of `make dist` as before without having it to list in _SOURCES.
It did't work, but it is not a problem.
+LIBBASICOBJECTS_0.1.0 { +global:
- simplebuffer_free;
- ...
+local:
- *;
+};
+LIBBASICOBJECTS_0.1.1 { +global:
- simplebuffer_get_vbuf;
+} LIBBASICOBJECTS_0.1.0;
Since this is the initial presence of symvers in the library, there is not specifically a need to have more than one symbol: there exists no program out there that already references the LIBBASICOBJECTS_0.1.0 symbol, so you can just put all symbols under _0.1.1. This also applies to all the other .sym files.
It was not necessary to write symvers in this way. I wanted to write reference implementation of version symbol file. So, it would be easy to extend symvers in the future even for beginners.
Referring to libini_config for this next example:
The symbol name is connected to the library, so it does not need to try to be unique across the entire system AFAICS. If you like you can make it shorter, for example "ABI_4 { ... }" to point out that these functions were added in version 4 (cf. libtool number in -version-info). Or V_4. Whichever :)
This is true. I checked installed libraries on my desktop and it seems to be unwritten rule to use uppercased name of library for this purpose. Some libraries contain also string LIB in this identifier e.g libidn.so.11 (LIBIDN_1.0), libxml2.so.2(LIBXML2_2.4.30) libvirt.so.0(LIBVIRT_0.0.3), libsystemd-daemon.so.0(LIBSYSTEMD_DAEMON_31) Other libraries ommit string LIB from identifier e.g libsolv.so.0(SOLV_1.0), libtevent.so.0(TEVENT_0.9.9) libgcrypt.so.11(GCRYPT_1.2), libnss3.so(NSS_3.2)
Only two libraries from package setools-libs use identifier VERS_4.1 e.g libseaudit.so.4, libapol.so.4
The biggest group uses upperace identifier without string LIB. I decided to remove "prefix" LIB.
Updated patch is attached
Thank you very much for your comments.
LS
Jan, Do you have any other comments to the patch from previous mail?
LS
On 03/07/2014 10:11 AM, Jan Engelhardt wrote:
On Friday 2014-03-07 15:15, Lukas Slebodnik wrote:
> attached patch addresses ticket #2193
Jan, Do you have any other comments to the patch from previous mail?
No further comments at this time. Please, just get it included already :} _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
I am preparing a new patch for ini and it will add two new entry points but I can't finish the work until your patch is pushed.
On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote:
On 03/07/2014 10:11 AM, Jan Engelhardt wrote:
On Friday 2014-03-07 15:15, Lukas Slebodnik wrote:
>>attached patch addresses ticket #2193
Jan, Do you have any other comments to the patch from previous mail?
No further comments at this time. Please, just get it included already :} _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
I am preparing a new patch for ini and it will add two new entry points but I can't finish the work until your patch is pushed.
ACK from me. make, make check, make distcheck and make rpms work fine.
SSSD also seems to be working fine after I upgraded ding-libs to the new RPMs.
On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote:
On 03/07/2014 10:11 AM, Jan Engelhardt wrote:
On Friday 2014-03-07 15:15, Lukas Slebodnik wrote:
>>>attached patch addresses ticket #2193
Jan, Do you have any other comments to the patch from previous mail?
No further comments at this time. Please, just get it included already :} _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
I am preparing a new patch for ini and it will add two new entry points but I can't finish the work until your patch is pushed.
ACK from me. make, make check, make distcheck and make rpms work fine.
SSSD also seems to be working fine after I upgraded ding-libs to the new RPMs.
Pushed to ding-libs master.
On 03/07/2014 12:00 PM, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote:
On 03/07/2014 10:11 AM, Jan Engelhardt wrote:
On Friday 2014-03-07 15:15, Lukas Slebodnik wrote:
>>>> attached patch addresses ticket #2193
Jan, Do you have any other comments to the patch from previous mail?
No further comments at this time. Please, just get it included already :} _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
I am preparing a new patch for ini and it will add two new entry points but I can't finish the work until your patch is pushed.
ACK from me. make, make check, make distcheck and make rpms work fine.
SSSD also seems to be working fine after I upgraded ding-libs to the new RPMs.
Pushed to ding-libs master. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
This push broke my deb builds on RHEL6:
[dpal@dpal ding-libs (master)]$ autoreconf -if libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'. libtoolize: copying file `build/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or Makefile.am:259: library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
On 03/08/2014 01:40 AM, Dmitri Pal wrote:
On 03/07/2014 12:00 PM, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote:
On 03/07/2014 10:11 AM, Jan Engelhardt wrote:
On Friday 2014-03-07 15:15, Lukas Slebodnik wrote:
>>>>> attached patch addresses ticket #2193 Jan, Do you have any other comments to the patch from previous mail?
No further comments at this time. Please, just get it included already :} _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
I am preparing a new patch for ini and it will add two new entry points but I can't finish the work until your patch is pushed.
ACK from me. make, make check, make distcheck and make rpms work fine.
SSSD also seems to be working fine after I upgraded ding-libs to the new RPMs.
Pushed to ding-libs master. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
This push broke my deb builds on RHEL6:
s/deb/dev
Also removing EXTRA_ prefix seems to fix the issue.
[dpal@dpal ding-libs (master)]$ autoreconf -if libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'. libtoolize: copying file `build/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or Makefile.am:259: library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
On Sat, Mar 08, 2014 at 02:00:45AM -0500, Dmitri Pal wrote:
On 03/08/2014 01:40 AM, Dmitri Pal wrote:
On 03/07/2014 12:00 PM, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote:
On 03/07/2014 10:11 AM, Jan Engelhardt wrote:
On Friday 2014-03-07 15:15, Lukas Slebodnik wrote: >>>>>>attached patch addresses ticket #2193 >Jan, >Do you have any other comments to the patch from previous mail? No further comments at this time. Please, just get it included already :} _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
I am preparing a new patch for ini and it will add two new entry points but I can't finish the work until your patch is pushed.
ACK from me. make, make check, make distcheck and make rpms work fine.
SSSD also seems to be working fine after I upgraded ding-libs to the new RPMs.
Pushed to ding-libs master. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
This push broke my deb builds on RHEL6:
s/deb/dev
Also removing EXTRA_ prefix seems to fix the issue.
Ouch. I just re-tested autoreconf locally on my F-20 box and it works fine. So there must be a difference between RHEL-6 and F-20's autoconf..
On (08/03/14 02:00), Dmitri Pal wrote:
On 03/08/2014 01:40 AM, Dmitri Pal wrote:
On 03/07/2014 12:00 PM, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote:
On 03/07/2014 10:11 AM, Jan Engelhardt wrote:
On Friday 2014-03-07 15:15, Lukas Slebodnik wrote: >>>>>>attached patch addresses ticket #2193 >Jan, >Do you have any other comments to the patch from previous mail? No further comments at this time. Please, just get it included already :} _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
I am preparing a new patch for ini and it will add two new entry points but I can't finish the work until your patch is pushed.
ACK from me. make, make check, make distcheck and make rpms work fine.
SSSD also seems to be working fine after I upgraded ding-libs to the new RPMs.
Pushed to ding-libs master. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
This push broke my deb builds on RHEL6:
s/deb/dev
Also removing EXTRA_ prefix seems to fix the issue.
[dpal@dpal ding-libs (master)]$ autoreconf -if libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'. libtoolize: copying file `build/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or Makefile.am:259: library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
The EXTRA_*_DEPENDENCIES variable is useful for cases where you merely want to augment the automake-generated _DEPENDENCIES variable rather than replacing it. http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Va...
It is a syntax warning in automake < 1.11.3 and syntax warnings are enabled by default. http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00008.html
Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
It would be better don't treat warnings as errors in automake.
The only negative of this solution is that library libini_conf will not be recompiled with older version of automake if files listed in EXTRA_*_DEPENDENCIES are changed. It is better to see warnings than override automatically generated dependencies calculated by automake with syntax: *_DEPENDENCIES
Patch is attached.
LS
On Mon, Mar 10, 2014 at 12:43:59PM +0100, Lukas Slebodnik wrote:
On (10/03/14 12:31), Jakub Hrozek wrote:
On Mon, Mar 10, 2014 at 07:30:40AM +0100, Lukas Slebodnik wrote:
Patch is attached.
It is not :-)
I would bet I attached patch.
LS
ACK
with this patch EXTRA_*_DEPENDENCIES are working as expected with recent automake versions and autoreconf does not fail with older versions.
bye, Sumit
On Thu, Apr 17, 2014 at 01:09:40PM +0200, Sumit Bose wrote:
On Mon, Mar 10, 2014 at 12:43:59PM +0100, Lukas Slebodnik wrote:
On (10/03/14 12:31), Jakub Hrozek wrote:
On Mon, Mar 10, 2014 at 07:30:40AM +0100, Lukas Slebodnik wrote:
Patch is attached.
It is not :-)
I would bet I attached patch.
LS
ACK
with this patch EXTRA_*_DEPENDENCIES are working as expected with recent automake versions and autoreconf does not fail with older versions.
bye, Sumit
Pushed to ding-libs master in eb98ff066b106af42b764d0fb260a94173309c31
On 03/10/2014 02:30 AM, Lukas Slebodnik wrote:
On (08/03/14 02:00), Dmitri Pal wrote:
On 03/08/2014 01:40 AM, Dmitri Pal wrote:
On 03/07/2014 12:00 PM, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote:
On 03/07/2014 10:11 AM, Jan Engelhardt wrote: > On Friday 2014-03-07 15:15, Lukas Slebodnik wrote: >>>>>>> attached patch addresses ticket #2193 >> Jan, >> Do you have any other comments to the patch from previous mail? > No further comments at this time. Please, just get it > included already :} > _______________________________________________ > sssd-devel mailing list > sssd-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel I am preparing a new patch for ini and it will add two new entry points but I can't finish the work until your patch is pushed.
ACK from me. make, make check, make distcheck and make rpms work fine.
SSSD also seems to be working fine after I upgraded ding-libs to the new RPMs.
Pushed to ding-libs master. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
This push broke my deb builds on RHEL6:
s/deb/dev
Also removing EXTRA_ prefix seems to fix the issue.
[dpal@dpal ding-libs (master)]$ autoreconf -if libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'. libtoolize: copying file `build/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or Makefile.am:259: library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
The EXTRA_*_DEPENDENCIES variable is useful for cases where you merely want to augment the automake-generated _DEPENDENCIES variable rather than replacing it. http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Va...
It is a syntax warning in automake< 1.11.3 and syntax warnings are enabled by default. http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00008.html
Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
It would be better don't treat warnings as errors in automake.
The only negative of this solution is that library libini_conf will not be recompiled with older version of automake if files listed in EXTRA_*_DEPENDENCIES are changed. It is better to see warnings than override automatically generated dependencies calculated by automake with syntax: *_DEPENDENCIES
Patch is attached.
LS
But you use EXTRA prefix only with libini_config and not with other libraries generated by this package. What is the difference? I would have understood if all libraries used EXTRA prefix but it is not the case. Or it is a bug?
Package that I have is 1.11.1. There is no other version available.
What is the recommendation with this issue?
On (10/03/14 14:31), Dmitri Pal wrote:
On 03/10/2014 02:30 AM, Lukas Slebodnik wrote:
On (08/03/14 02:00), Dmitri Pal wrote:
On 03/08/2014 01:40 AM, Dmitri Pal wrote:
On 03/07/2014 12:00 PM, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote: >On 03/07/2014 10:11 AM, Jan Engelhardt wrote: >>On Friday 2014-03-07 15:15, Lukas Slebodnik wrote: >>>>>>>>attached patch addresses ticket #2193 >>>Jan, >>>Do you have any other comments to the patch from previous mail? >>No further comments at this time. Please, just get it >>included already :} >>_______________________________________________ >>sssd-devel mailing list >>sssd-devel@lists.fedorahosted.org >>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel >I am preparing a new patch for ini and it will add two new entry >points but I can't finish the work until your patch is pushed. ACK from me. make, make check, make distcheck and make rpms work fine.
SSSD also seems to be working fine after I upgraded ding-libs to the new RPMs.
Pushed to ding-libs master. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
This push broke my deb builds on RHEL6:
s/deb/dev
Also removing EXTRA_ prefix seems to fix the issue.
[dpal@dpal ding-libs (master)]$ autoreconf -if libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'. libtoolize: copying file `build/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or Makefile.am:259: library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
The EXTRA_*_DEPENDENCIES variable is useful for cases where you merely want to augment the automake-generated _DEPENDENCIES variable rather than replacing it. http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Va...
It is a syntax warning in automake< 1.11.3 and syntax warnings are enabled by default. http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00008.html
Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
It would be better don't treat warnings as errors in automake.
The only negative of this solution is that library libini_conf will not be recompiled with older version of automake if files listed in EXTRA_*_DEPENDENCIES are changed. It is better to see warnings than override automatically generated dependencies calculated by automake with syntax: *_DEPENDENCIES
Patch is attached.
LS
If _DEPENDENCIES is not supplied, it is computed by Automake. The automatically-assigned value is the contents of _LDADD or _LIBADD, with most configure substitutions, -l, -L, -dlopen and -dlpreopen options removed.
_DEPENDENCIES will overrride aotomatically generated dependencies because automake knows that author did it intentionaly and author has a good reason for this.
The EXTRA_*_DEPENDENCIES variable may be useful for cases where you merely want to augment the automake-generated _DEPENDENCIES variable rather than replacing it.
But you use EXTRA prefix only with libini_config and not with other libraries generated by this package. What is the difference?
libpath_utils, libdhash, libcollection, libref_array, libbasicobjects are simple libraries and do not depend on other library. It is possible to use *_DEPENDENCIES because nothing will be overridden. EXTRA_*_DEPENDENCIES could be used as well.
libini_config depends on the other libraries.
libini_config_la_LIBADD = \ libcollection.la \ libpath_utils.la \ libref_array.la \ libbasicobjects.la
1st version: libini_config_la_DEPENDENCIES = ini/libini_config.sym
The previous line will replace automake-generated dependencies. If libcollection is changed libini_config will not be rebuilt. Yes, you can still use: make clean && make to workaround this problem. It can cause weird behaviour if you forget to clean project.
2nd version: EXTRA_libini_config_la_DEPENDENCIES = ini/libini_config.sym
It works as expected with newer automake.
With automake < 1.11.3, EXTRA_*_DEPENDENCIES is ignored (unknown syntax) Automake-generated dependencies are not replaced. There is drawback libini_config will not be rebuilt if file ini/libini_config.sym is changed. Again, you can still use: make clean && make to workaround this problem. libini_config.sym will be usually changed together with other source codes. So, it is not very likely you will hit this situation.
I would have understood if all libraries used EXTRA prefix but it is not the case. Or it is a bug?
Package that I have is 1.11.1. There is no other version available.
What is the recommendation with this issue?
I was thinking about this issue and I can see yet another solution (workaround) which should work with older verions of automake.
3rd version: We can add all dependencies manually because ding-libs doesn't have complicated dependencies
libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ libcollection.la \ libpath_utils.la \ libref_array.la \ libbasicobjects.la
or shorter version: libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ $(libini_config_la_LIBADD)
I can see two options: 2nd version and do not treat automake warnings as errors 3rd version (workaround)
LS
BTW: automake warnings EXTRA_*_DEPENDENCIES are also in sssd. But each sssd developer use at least fedora 17. We can ignore this warning on el6 build.
On Mon, Mar 10, 2014 at 10:28:51PM +0100, Lukas Slebodnik wrote:
On (10/03/14 14:31), Dmitri Pal wrote:
On 03/10/2014 02:30 AM, Lukas Slebodnik wrote:
On (08/03/14 02:00), Dmitri Pal wrote:
On 03/08/2014 01:40 AM, Dmitri Pal wrote:
On 03/07/2014 12:00 PM, Jakub Hrozek wrote:
On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote: >On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote: >>On 03/07/2014 10:11 AM, Jan Engelhardt wrote: >>>On Friday 2014-03-07 15:15, Lukas Slebodnik wrote: >>>>>>>>>attached patch addresses ticket #2193 >>>>Jan, >>>>Do you have any other comments to the patch from previous mail? >>>No further comments at this time. Please, just get it >>>included already :} >>>_______________________________________________ >>>sssd-devel mailing list >>>sssd-devel@lists.fedorahosted.org >>>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel >>I am preparing a new patch for ini and it will add two new entry >>points but I can't finish the work until your patch is pushed. >ACK from me. make, make check, make distcheck and make rpms work fine. > >SSSD also seems to be working fine after I upgraded ding-libs >to the new >RPMs. Pushed to ding-libs master. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
This push broke my deb builds on RHEL6:
s/deb/dev
Also removing EXTRA_ prefix seems to fix the issue.
[dpal@dpal ding-libs (master)]$ autoreconf -if libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'. libtoolize: copying file `build/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or Makefile.am:259: library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
The EXTRA_*_DEPENDENCIES variable is useful for cases where you merely want to augment the automake-generated _DEPENDENCIES variable rather than replacing it. http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Va...
It is a syntax warning in automake< 1.11.3 and syntax warnings are enabled by default. http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00008.html
Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
It would be better don't treat warnings as errors in automake.
The only negative of this solution is that library libini_conf will not be recompiled with older version of automake if files listed in EXTRA_*_DEPENDENCIES are changed. It is better to see warnings than override automatically generated dependencies calculated by automake with syntax: *_DEPENDENCIES
Patch is attached.
LS
If _DEPENDENCIES is not supplied, it is computed by Automake. The automatically-assigned value is the contents of _LDADD or _LIBADD, with most configure substitutions, -l, -L, -dlopen and -dlpreopen options removed.
_DEPENDENCIES will overrride aotomatically generated dependencies because automake knows that author did it intentionaly and author has a good reason for this.
The EXTRA_*_DEPENDENCIES variable may be useful for cases where you merely want to augment the automake-generated _DEPENDENCIES variable rather than replacing it.
But you use EXTRA prefix only with libini_config and not with other libraries generated by this package. What is the difference?
libpath_utils, libdhash, libcollection, libref_array, libbasicobjects are simple libraries and do not depend on other library. It is possible to use *_DEPENDENCIES because nothing will be overridden. EXTRA_*_DEPENDENCIES could be used as well.
libini_config depends on the other libraries.
libini_config_la_LIBADD = \ libcollection.la \ libpath_utils.la \ libref_array.la \ libbasicobjects.la
1st version: libini_config_la_DEPENDENCIES = ini/libini_config.sym
The previous line will replace automake-generated dependencies. If libcollection is changed libini_config will not be rebuilt. Yes, you can still use: make clean && make to workaround this problem. It can cause weird behaviour if you forget to clean project.
2nd version: EXTRA_libini_config_la_DEPENDENCIES = ini/libini_config.sym
It works as expected with newer automake.
With automake < 1.11.3, EXTRA_*_DEPENDENCIES is ignored (unknown syntax) Automake-generated dependencies are not replaced. There is drawback libini_config will not be rebuilt if file ini/libini_config.sym is changed. Again, you can still use: make clean && make to workaround this problem. libini_config.sym will be usually changed together with other source codes. So, it is not very likely you will hit this situation.
I would have understood if all libraries used EXTRA prefix but it is not the case. Or it is a bug?
Package that I have is 1.11.1. There is no other version available.
What is the recommendation with this issue?
I was thinking about this issue and I can see yet another solution (workaround) which should work with older verions of automake.
3rd version: We can add all dependencies manually because ding-libs doesn't have complicated dependencies
libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ libcollection.la \ libpath_utils.la \ libref_array.la \ libbasicobjects.la
or shorter version: libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ $(libini_config_la_LIBADD)
I can see two options: 2nd version and do not treat automake warnings as errors 3rd version (workaround)
LS
BTW: automake warnings EXTRA_*_DEPENDENCIES are also in sssd. But each sssd developer use at least fedora 17. We can ignore this warning on el6 build.
I'm sorry, I forgot about this patch and didn't come back until I was checking stale threads in patchwork today..
I would prefer to ignore automake warnings. Given the wide range of host OS we support ranging from RHEL-6 to latest Fedora we're going to continue running into incompatibilities and warninigs. I would prefer to treat them as non-fatal if possible.
Do you see some downside to this? Do you anticipate that ignoring some warnigns might cause a wrong build?
On (07/04/14 18:57), Jakub Hrozek wrote:
On Mon, Mar 10, 2014 at 10:28:51PM +0100, Lukas Slebodnik wrote:
On (10/03/14 14:31), Dmitri Pal wrote:
On 03/10/2014 02:30 AM, Lukas Slebodnik wrote:
On (08/03/14 02:00), Dmitri Pal wrote:
On 03/08/2014 01:40 AM, Dmitri Pal wrote:
On 03/07/2014 12:00 PM, Jakub Hrozek wrote: >On Fri, Mar 07, 2014 at 05:49:44PM +0100, Jakub Hrozek wrote: >>On Fri, Mar 07, 2014 at 10:19:11AM -0500, Dmitri Pal wrote: >>>On 03/07/2014 10:11 AM, Jan Engelhardt wrote: >>>>On Friday 2014-03-07 15:15, Lukas Slebodnik wrote: >>>>>>>>>>attached patch addresses ticket #2193 >>>>>Jan, >>>>>Do you have any other comments to the patch from previous mail? >>>>No further comments at this time. Please, just get it >>>>included already :} >>>>_______________________________________________ >>>>sssd-devel mailing list >>>>sssd-devel@lists.fedorahosted.org >>>>https://lists.fedorahosted.org/mailman/listinfo/sssd-devel >>>I am preparing a new patch for ini and it will add two new entry >>>points but I can't finish the work until your patch is pushed. >>ACK from me. make, make check, make distcheck and make rpms work fine. >> >>SSSD also seems to be working fine after I upgraded ding-libs >>to the new >>RPMs. >Pushed to ding-libs master. >_______________________________________________ >sssd-devel mailing list >sssd-devel@lists.fedorahosted.org >https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
This push broke my deb builds on RHEL6:
s/deb/dev
Also removing EXTRA_ prefix seems to fix the issue.
[dpal@dpal ding-libs (master)]$ autoreconf -if libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build'. libtoolize: copying file `build/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or Makefile.am:259: library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
The EXTRA_*_DEPENDENCIES variable is useful for cases where you merely want to augment the automake-generated _DEPENDENCIES variable rather than replacing it. http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Va...
It is a syntax warning in automake< 1.11.3 and syntax warnings are enabled by default. http://lists.gnu.org/archive/html/automake-patches/2010-10/msg00008.html
Makefile.am:259: variable `EXTRA_libini_config_la_DEPENDENCIES' is defined but no program or library has `EXTRA_libini_config_la' as canonical name (possible typo) autoreconf: automake failed with exit status: 1
It would be better don't treat warnings as errors in automake.
The only negative of this solution is that library libini_conf will not be recompiled with older version of automake if files listed in EXTRA_*_DEPENDENCIES are changed. It is better to see warnings than override automatically generated dependencies calculated by automake with syntax: *_DEPENDENCIES
Patch is attached.
LS
If _DEPENDENCIES is not supplied, it is computed by Automake. The automatically-assigned value is the contents of _LDADD or _LIBADD, with most configure substitutions, -l, -L, -dlopen and -dlpreopen options removed.
_DEPENDENCIES will overrride aotomatically generated dependencies because automake knows that author did it intentionaly and author has a good reason for this.
The EXTRA_*_DEPENDENCIES variable may be useful for cases where you merely want to augment the automake-generated _DEPENDENCIES variable rather than replacing it.
But you use EXTRA prefix only with libini_config and not with other libraries generated by this package. What is the difference?
libpath_utils, libdhash, libcollection, libref_array, libbasicobjects are simple libraries and do not depend on other library. It is possible to use *_DEPENDENCIES because nothing will be overridden. EXTRA_*_DEPENDENCIES could be used as well.
libini_config depends on the other libraries.
libini_config_la_LIBADD = \ libcollection.la \ libpath_utils.la \ libref_array.la \ libbasicobjects.la
1st version: libini_config_la_DEPENDENCIES = ini/libini_config.sym
The previous line will replace automake-generated dependencies. If libcollection is changed libini_config will not be rebuilt. Yes, you can still use: make clean && make to workaround this problem. It can cause weird behaviour if you forget to clean project.
2nd version: EXTRA_libini_config_la_DEPENDENCIES = ini/libini_config.sym
It works as expected with newer automake.
With automake < 1.11.3, EXTRA_*_DEPENDENCIES is ignored (unknown syntax) Automake-generated dependencies are not replaced. There is drawback libini_config will not be rebuilt if file ini/libini_config.sym is changed. Again, you can still use: make clean && make to workaround this problem. libini_config.sym will be usually changed together with other source codes. So, it is not very likely you will hit this situation.
I would have understood if all libraries used EXTRA prefix but it is not the case. Or it is a bug?
Package that I have is 1.11.1. There is no other version available.
What is the recommendation with this issue?
I was thinking about this issue and I can see yet another solution (workaround) which should work with older verions of automake.
3rd version: We can add all dependencies manually because ding-libs doesn't have complicated dependencies
libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ libcollection.la \ libpath_utils.la \ libref_array.la \ libbasicobjects.la
or shorter version: libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ $(libini_config_la_LIBADD)
I can see two options: 2nd version and do not treat automake warnings as errors 3rd version (workaround)
LS
BTW: automake warnings EXTRA_*_DEPENDENCIES are also in sssd. But each sssd developer use at least fedora 17. We can ignore this warning on el6 build.
I'm sorry, I forgot about this patch and didn't come back until I was checking stale threads in patchwork today..
I would prefer to ignore automake warnings. Given the wide range of host OS we support ranging from RHEL-6 to latest Fedora we're going to continue running into incompatibilities and warninigs. I would prefer to treat them as non-fatal if possible.
Do you see some downside to this? Do you anticipate that ignoring some warnigns might cause a wrong build?
Ignoring error with older automake: The only drawback is libraries will not rebuilt on RHEL6 if version symbol files are changed.
Next commands will not have any effect. touch ini/libini_config.sym make
Workaround is to use make clean && make (or touch any other source file) We are doing review on fedora 19+. We will catch warnings from newer automake.
If we don not want to have warning on rhel6 we can maintain dependencies manually because ding-libs doesn't have complicated dependencies. libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ $(libini_config_la_LIBADD)
LS
On Tue, Apr 08, 2014 at 02:56:10PM +0200, Lukas Slebodnik wrote:
Ignoring error with older automake: The only drawback is libraries will not rebuilt on RHEL6 if version symbol files are changed.
Next commands will not have any effect. touch ini/libini_config.sym make
Workaround is to use make clean && make (or touch any other source file) We are doing review on fedora 19+. We will catch warnings from newer automake.
If we don not want to have warning on rhel6 we can maintain dependencies manually because ding-libs doesn't have complicated dependencies. libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ $(libini_config_la_LIBADD)
LS
I would personally prefer to ignore warnings on an older release (which will go EOL eventually) and see the warnings on our devel platforms rather than having to maintain dependencies manually forever.
On Mon, Apr 14, 2014 at 04:25:27PM +0200, Jakub Hrozek wrote:
On Tue, Apr 08, 2014 at 02:56:10PM +0200, Lukas Slebodnik wrote:
Ignoring error with older automake: The only drawback is libraries will not rebuilt on RHEL6 if version symbol files are changed.
Next commands will not have any effect. touch ini/libini_config.sym make
Workaround is to use make clean && make (or touch any other source file) We are doing review on fedora 19+. We will catch warnings from newer automake.
If we don not want to have warning on rhel6 we can maintain dependencies manually because ding-libs doesn't have complicated dependencies. libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ $(libini_config_la_LIBADD)
LS
I would personally prefer to ignore warnings on an older release (which will go EOL eventually) and see the warnings on our devel platforms rather than having to maintain dependencies manually forever.
I agree, I like the 2nd version
EXTRA_libini_config_la_DEPENDENCIES = ini/libini_config.sym
best.
bye, Sumit
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On (14/04/14 18:23), Sumit Bose wrote:
On Mon, Apr 14, 2014 at 04:25:27PM +0200, Jakub Hrozek wrote:
On Tue, Apr 08, 2014 at 02:56:10PM +0200, Lukas Slebodnik wrote:
Ignoring error with older automake: The only drawback is libraries will not rebuilt on RHEL6 if version symbol files are changed.
Next commands will not have any effect. touch ini/libini_config.sym make
Workaround is to use make clean && make (or touch any other source file) We are doing review on fedora 19+. We will catch warnings from newer automake.
If we don not want to have warning on rhel6 we can maintain dependencies manually because ding-libs doesn't have complicated dependencies. libini_config_la_DEPENDENCIES = \ ini/libini_config.sym \ $(libini_config_la_LIBADD)
LS
I would personally prefer to ignore warnings on an older release (which will go EOL eventually) and see the warnings on our devel platforms rather than having to maintain dependencies manually forever.
I agree, I like the 2nd version
EXTRA_libini_config_la_DEPENDENCIES = ini/libini_config.sym
best.
bye, Sumit
Jakub, Sumit thank you very much for comments. The patch for the 2nd solution was already sent on Monday March 10
https://lists.fedorahosted.org/pipermail/sssd-devel/2014-March/018739.html
LS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
Given that it's never intended to be used by anything but the unit tests, I'd much prefer that it be built as a separate object file and just statically linked into the test and the library. Then we don't need to expose it from the library. Not that I expect anyone is going to use it, but this is better behavior.
On 01/16/2014 10:43 AM, Stephen Gallagher wrote:
On 01/13/2014 01:42 PM, Lukas Slebodnik wrote:
ehlo,
attached patch addresses ticket #2193
I have just a question about refarray/libref_array.sym There is extern function ref_array_debug, which is not defined in public header file (not exposed in public API), but it is used in ref_array unit tests. It needs to be in global section because linker with fail to find symbol. Should I add any comment to the file libref_array.sym or does anyone better solution?
Given that it's never intended to be used by anything but the unit tests, I'd much prefer that it be built as a separate object file and just statically linked into the test and the library. Then we don't need to expose it from the library. Not that I expect anyone is going to use it, but this is better behavior.
This is what I suggested too but it is a bit of work... Let me investigate today and I will come back to you.
sssd-devel@lists.fedorahosted.org