Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.1
    • Component/s: Build
    • Labels:
      None

      Description

      When applying a patch, the dependency system did not correctly rebuild Prefetch.o
      as well as some other files for changes to I_IOBuffer.h

      Back out the attached patch and then reapply without doing a 'make clean' to see the problem.

        Activity

        Hide
        Andrew Hsu added a comment -

        From IRC chat conversation:

        andrewhsu: hmm...i notice that files like AbstractBuffer.cc is specified as a SOURCES for libTrafficServerStandalone and traffic_server. but ICP.cc is only specified as a SOURCES for traffic_server. it also looks like .Po files are created for all .cc files upon the first execution of `make`. it may be that ICP.Po is created but never used by the build system (because it already has traffic_server-ICP.Po). but for some reason files like AbstractBuffer.Po is created and then used in the final 'Makefile' that is generated.

        I believe the fix is to not have the logstat, logcat, etc files LDADD the .o files directly, but instead have a static library shared between the linking of various binaries so the deps link up properly.

        For now, workaround is to do `make clean` if you know you are changing a file that is not linked up properly with deps.

        I'll take ownership of this jira.

        Show
        Andrew Hsu added a comment - From IRC chat conversation: andrewhsu: hmm...i notice that files like AbstractBuffer.cc is specified as a SOURCES for libTrafficServerStandalone and traffic_server. but ICP.cc is only specified as a SOURCES for traffic_server. it also looks like .Po files are created for all .cc files upon the first execution of `make`. it may be that ICP.Po is created but never used by the build system (because it already has traffic_server-ICP.Po). but for some reason files like AbstractBuffer.Po is created and then used in the final 'Makefile' that is generated. I believe the fix is to not have the logstat, logcat, etc files LDADD the .o files directly, but instead have a static library shared between the linking of various binaries so the deps link up properly. For now, workaround is to do `make clean` if you know you are changing a file that is not linked up properly with deps. I'll take ownership of this jira.
        Hide
        John Plevyak added a comment -

        Another interesting thing I noticed is that if one does a 'make'
        in the proxy directory, it will rebuild the executable but not
        rebuild the other libraries (not under proxy). This is a bit
        confusing. I would think that either it would not build an executable
        or it would rebuild the libraries as well.

        Show
        John Plevyak added a comment - Another interesting thing I noticed is that if one does a 'make' in the proxy directory, it will rebuild the executable but not rebuild the other libraries (not under proxy). This is a bit confusing. I would think that either it would not build an executable or it would rebuild the libraries as well.
        Hide
        John Plevyak added a comment -

        I fixed part of this by making the flags identical for all the targets so that there would only be one set of .Po files.

        Show
        John Plevyak added a comment - I fixed part of this by making the flags identical for all the targets so that there would only be one set of .Po files.
        Hide
        John Plevyak added a comment -

        I think this is fixed, so I am moving it off the 2.1.0 until Andrew has time to take a look at it.

        Show
        John Plevyak added a comment - I think this is fixed, so I am moving it off the 2.1.0 until Andrew has time to take a look at it.
        Hide
        Leif Hedstrom added a comment -

        I'm closing this for now, Andrew please reopen if you think it's still an issue.

        Show
        Leif Hedstrom added a comment - I'm closing this for now, Andrew please reopen if you think it's still an issue.

          People

          • Assignee:
            Andrew Hsu
            Reporter:
            John Plevyak
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development