llvm-3.4 does not build on PPC Tiger (Mac OS X 10.4.11) because ..../llvm-3.4/work/llvm-3.4.2.src/Makefile.config was not built yet

[ballapete (Peter "Pete" Dyballa)]

configure: creating ./config.status
config.status: creating Makefile.common
config.status: creating Makefile.llvm.config
config.status: executing setup commands
config.status: executing Makefile commands
config.status: executing lib/Makefile commands
config.status: executing lib/sample/Makefile commands
config.status: executing tools/Makefile commands
config.status: executing tools/sample/Makefile commands
DEBUG: Executing proc-post-org.macports.configure-configure-0
--->  Patching Makefile.config: /^RPATH/s/=.*/=/
DEBUG: Executing reinplace: /usr/bin/sed /^RPATH/s/=.*/=/ < /opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_lang_llvm-3.4/llvm-3.4/work/llvm-3.4.2.src/Makefile.config >@ file10 2>@stderr
DEBUG: couldn't read file "/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_lang_llvm-3.4/llvm-3.4/work/llvm-3.4.2.src/Makefile.config": no such file or directory
    while executing
"exec /usr/bin/sed /^RPATH/s/=.*/=/ < /opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_la..."
    ("eval" body line 1)
    invoked from within
"eval exec $cmdline"
Error: reinplace: couldn't read file "/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_lang_llvm-3.4/llvm-3.4/work/llvm-3.4.2.src/Makefile.config": no such file or directory
Error: org.macports.configure for port llvm-3.4 returned: reinplace sed(1) failed

The directory /opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_lang_llvm-3.4/llvm-3.4/work/llvm-3.4.2.src only contains:

-rw-r--r--  1 macports admin  18191 12. Mai 2014  CMakeLists.txt
-rw-r--r--  1 macports admin   3231  7. Dez 2013  CODE_OWNERS.TXT
-rw-r--r--  1 macports admin  10390 17. Nov 2013  CREDITS.TXT
-rw-r--r--  1 macports admin   3331 21. Mai 2013  LICENSE.TXT
-rw-r--r--  1 macports admin    744  2. Okt 2013  LLVMBuild.txt
-rw-r--r--  1 macports admin   8704 11. Jul 16:55 Makefile
-rw-r--r--  1 macports admin   2599  7. Dez 2012  Makefile.common
-rw-r--r--  1 macports admin  12599 19. Mär 2014  Makefile.config.in   <===
-rw-r--r--  1 macports admin  72255 11. Jul 16:55 Makefile.rules
-rw-r--r--  1 macports admin    688  4. Okt 2013  README.txt
drwxr-xr-x 15 macports admin    510 13. Jun 2014  autoconf
drwxr-xr-x  7 macports admin    238 13. Jun 2014  bindings
drwxr-xr-x  7 macports admin    238 13. Jun 2014  cmake
-rwxr-xr-x  1 macports admin 679546 11. Jul 16:55 configure
drwxr-xr-x 90 macports admin   3060 13. Jun 2014  docs
drwxr-xr-x 13 macports admin    442 13. Jun 2014  examples
drwxr-xr-x  4 macports admin    136 13. Jun 2014  include
drwxr-xr-x 22 macports admin    748 13. Jun 2014  lib
-rw-r--r--  1 macports admin   1865 25. Jan 2012  llvm.spec.in
drwxr-xr-x  6 macports admin    204 13. Jun 2014  projects
drwxr-xr-x 33 macports admin   1122 13. Jun 2014  test
drwxr-xr-x 39 macports admin   1326 13. Jun 2014  tools
drwxr-xr-x 18 macports admin    612 11. Jul 16:55 unittests
drwxr-xr-x 59 macports admin   2006 13. Jun 2014  utils

[ballapete (Peter "Pete" Dyballa)]

main.log

[jeremyhu (Jeremy Huddleston Sequoia)]

Likely fallout from r136583

[jeremyhu (Jeremy Huddleston Sequoia)]

Peter, if you change the failing reinplace to change the file in ${build.dir} instead of ${worksrcpath}, does that fix the issue for you?

[larryv (Lawrence Velázquez)]

Oops, my fault. Looks like llvm-3.3 is affected also.

Peter, can you verify that r138538 fixes this?

[ballapete (Peter "Pete" Dyballa)]

Replying to jeremyhu@…:

Peter, if you change the failing reinplace to change the file in ${build.dir} instead of ${worksrcpath}, does that fix the issue for you?

I learned to use port -n and now port is upgrading libgcc, gcc48, and gcc49. I think this will end on Monday or Tuesday…

[ballapete (Peter "Pete" Dyballa)]

Replying to larryv@…:

Oops, my fault. Looks like llvm-3.3 is affected also.

Peter, can you verify that r138538 fixes this?

I learned to use port -n and now port is upgrading libgcc, gcc48, and gcc49. I think this will end on Monday or Tuesday…

[larryv (Lawrence Velázquez)]

I doubt it will cause any problems in this particular case, since GCC only uses LLVM for libLTO.dylib via ld64, but you really, really should not get into the habit of using port -n.

[ballapete (Peter "Pete" Dyballa)]

Replying to larryv@…:

I doubt it will cause any problems in this particular case, since GCC only uses LLVM for libLTO.dylib via ld64, but you really, really should not get into the habit of using port -n.

I did not see that dependency although I tried to check it. Probably I should always use rdepof:! The reason to use -n is that I wanted to use the time it takes to fix an issue with gettext to install some ports that do not depend on it. And a lot of ports seem to depend on gettext directly or indirectly!

[ballapete (Peter "Pete" Dyballa)]

Replying to larryv@…:

Oops, my fault. Looks like llvm-3.3 is affected also.

Peter, can you verify that r138538 fixes this?

I selfupdated after GCC4[89] were built and the build of llvm-3.4 is now in its configure phase. So the original bug was fixed. OK, already compiling!