QA Notice: Files built without respecting LDFLAGS have been detected Please include the following list of files in your report: /usr/lib64/erlang/lib/runtime_tools-1.7.3/priv/lib/trace_file_drv.so /usr/lib64/erlang/lib/runtime_tools-1.7.3/priv/lib/trace_ip_drv.so /usr/lib64/erlang/lib/megaco-3.9.1.1/priv/lib/megaco_flex_scanner_drv_mt.so /usr/lib64/erlang/lib/megaco-3.9.1.1/priv/lib/megaco_flex_scanner_drv.so /usr/lib64/erlang/lib/erl_interface-3.5.9/bin/erl_call /usr/lib64/erlang/lib/ssl-3.10/priv/bin/ssl_esock /usr/lib64/erlang/lib/asn1-1.6.2/priv/lib/asn1_erl_drv.so /usr/lib64/erlang/lib/crypto-1.5.3/priv/lib/crypto_drv.so /usr/lib64/erlang/lib/common_test-1.3.4/priv/lib/erl_rx_driver.so /usr/lib64/erlang/erts-5.6.5/bin/child_setup
Thank you for your report and sorry for the delay. Before digging too deep into why LDFLAGS are ignored, upstream should be contacted. Are you able to take that over? If not, I will try to get in touch with them. They are usually really helpful on the erlang-bugs mailing list.
Upstream informed. http://www.erlang.org/pipermail/erlang-bugs/2009-March/001248.html
(In reply to comment #2) > Upstream informed. Thanks, let's see if they react sometime...sometimes they fix the problems and just don't tell anyone.
Btw, Erlang/OTP R13A was recently released. Maybe this bug is fixed in the new version. I'll test it if you can update the package (a masked bump should be fine since upstream considers it a beta release).
Created attachment 187253 [details] Draft ebuild for Erlang 13A (In reply to comment #4) > Btw, Erlang/OTP R13A was recently released. Maybe this bug is fixed in the new > version. I'll test it if you can update the package (a masked bump should be > fine since upstream considers it a beta release). Yes, have seen it. It has some bigger news and dependencies will likely be updated (wxGTK being one of them) so I won't add ebuilds to Portage now, as I need to rework the ebuild quite a bit (no time at the moment for that). But you can try the ebuild attached, which is just tested for a succesful configure run.
Still a problem in R13A. * QA Notice: Files built without respecting LDFLAGS have been detected * Please include the following list of files in your report: * /usr/lib64/erlang/lib/runtime_tools-1.8/priv/lib/trace_file_drv.so * /usr/lib64/erlang/lib/runtime_tools-1.8/priv/lib/trace_ip_drv.so * /usr/lib64/erlang/lib/erl_interface-3.6/bin/erl_call * /usr/lib64/erlang/lib/crypto-1.6/priv/lib/crypto_drv.so * /usr/lib64/erlang/lib/megaco-3.10.0.1/priv/lib/megaco_flex_scanner_drv_mt.so * /usr/lib64/erlang/lib/megaco-3.10.0.1/priv/lib/megaco_flex_scanner_drv.so * /usr/lib64/erlang/lib/ssl-3.10.1/priv/bin/ssl_esock * /usr/lib64/erlang/lib/asn1-1.6.8/priv/lib/asn1_erl_drv.so * /usr/lib64/erlang/erts-5.7/bin/child_setup I had to disable 'java' USE flag because otherwise compilation fails with a java.lang.OutOfMemoryError exception.
(In reply to comment #6) > Still a problem in R13A. > > * QA Notice: Files built without respecting LDFLAGS have been detected > * Please include the following list of files in your report: > * /usr/lib64/erlang/lib/runtime_tools-1.8/priv/lib/trace_file_drv.so > * /usr/lib64/erlang/lib/runtime_tools-1.8/priv/lib/trace_ip_drv.so > * /usr/lib64/erlang/lib/erl_interface-3.6/bin/erl_call > * /usr/lib64/erlang/lib/crypto-1.6/priv/lib/crypto_drv.so > * /usr/lib64/erlang/lib/megaco-3.10.0.1/priv/lib/megaco_flex_scanner_drv_mt.so > * /usr/lib64/erlang/lib/megaco-3.10.0.1/priv/lib/megaco_flex_scanner_drv.so > * /usr/lib64/erlang/lib/ssl-3.10.1/priv/bin/ssl_esock > * /usr/lib64/erlang/lib/asn1-1.6.8/priv/lib/asn1_erl_drv.so > * /usr/lib64/erlang/erts-5.7/bin/child_setup > > > I had to disable 'java' USE flag because otherwise compilation fails with a > java.lang.OutOfMemoryError exception. No problems here...how much space is left on your /var/tmp/portage partition (if any) and how much RAM do you have? Erlang 13A is in the tree now (masked with extended USE flags).
2 GB of ram and 15 GB of free disk space. I think the failure is unrelated to this specific package though, because I've seen very weird interactions between my kernel and the jvm lately. The jvm process gets stuck on a futex and while it remains there, any other fork() fails... maybe the kernel is out of file descriptors? I'll investigate this issue further and open another bug if appropriate. Btw, I'm having a look at erlang's build system... it's quite a bit of a mess and has lots of duplicated code... it really needs a rewrite using libtool imho. Anyway I managed to prepare a working patch that fixes the LDFLAGS problem for me, I'll attach it shortly.
Created attachment 187637 [details, diff] respect LDFLAGS
(In reply to comment #8) > Btw, I'm having a look at erlang's build system... it's quite a bit of a mess > and has lots of duplicated code... it really needs a rewrite using libtool > imho. Anyway I managed to prepare a working patch that fixes the LDFLAGS > problem for me, I'll attach it shortly. Thanks for your patch. 13.1-r1 is in the tree, please bring the patch upstream. I am maintaining Erlang for two years now and apart from the build system, maintaining the ebuild is a real pain, too...and I don't even use Erlang: http://www.faulhammer.org/archiv-mainmenu-31/35-gentoo/142-never-bump-a-package-you-dont-want-to-maintain
For the record, my patch has been accepted upstream and will be included in the first patch release after R13B. http://erlang.org/pipermail/erlang-bugs/2009-April/001271.html
(In reply to comment #11) > For the record, my patch has been accepted upstream and will be included in the > first patch release after R13B. Thanks a lot for your work, I really appreciate it. Now you can fix their build system to support parallel buids. :)
I just rebuilt erlang-13.2.1 and found that the original issue is still present. My patch still applies cleanly, so I guess upstream forgot to apply it before the release... :(
(In reply to comment #13) > I just rebuilt erlang-13.2.1 and found that the original issue is still > present. My patch still applies cleanly, so I guess upstream forgot to apply it > before the release... :( Readded to Portage. Please resubmit the patch. Thanks for the notice.
*** Bug 335964 has been marked as a duplicate of this bug. ***
Some parts of the patch have not been applied, I rereported it upstream.
Fixed in 14.2
