From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 01/15 v2] makefiles: Fixed -share command line option error Date: Fri, 02 May 2014 15:18:38 +0200 Message-ID: <1894591.lg32KUJbpS@xps13> References: <1397585169-14537-2-git-send-email-nhorman@tuxdriver.com> <3290487.cx3MKzuIo9@xps13> <20140502130148.GD15335@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Neil Horman Return-path: In-Reply-To: <20140502130148.GD15335-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 2014-05-02 09:01, Neil Horman: > On Fri, May 02, 2014 at 02:22:17PM +0200, Thomas Monjalon wrote: > > 2014-05-02 07:09, Neil Horman: > > > On Wed, Apr 30, 2014 at 01:42:12AM +0200, Thomas Monjalon wrote: > > > > 2014-04-16 09:51, Neil Horman: > > > > > The shared libraries built with the current makefile set produce > > > > > static > > > > > libraries rather than actual shared objects. This is due to several > > > > > missing options that are required to correctly build shared objects > > > > > using ld, as well as a mis-specified -share option (which should be > > > > > -shared). Switching to the use of CC rather than LD and fixing the > > > > > -shared option corrects these problems and builds the DSOs > > > > > correctly. > > > > > > > > > > Signed-off-by: Neil Horman > > > > > > > > Applied for version 1.6.0r2. > > > > > > So, I just went and looked at 1.6.0r2 and noted that you applied this > > > patch, but the rest of the series is still missing. This is what I was > > > talking about earlier when I said you weren't applying patch series > > > atomically. It makes it impossible to have any clue what the upstream > > > development head is going to look like. On top of that, since you're > > > clearly integrating other changes ahead of this, theres every > > > likelyhood the rest of my v5 series won't apply. > > > > > > the v5 series has sat out here for a few weeks now without comment. If > > > there aren't any objections to it, apply it. Whats the problem here? > > > I'm not going to package the DPDK until this series (or the > > > functionality it offers) is in place. > > > > This patch is clearly an important fix. So I took it for release 1.6.0r2. > > The other patches of the serie are enhancements which will be in 1.7.0. > > > > The goal is to change the integration model. > > Now we'll stop integrating enhancements and big changes when first release > > candidate is out. Then it will be clear that only fixes and mandatory > > changes will be integrated in the last part of the release cycle. > > > > I hope you agree we're improving the workflow. > > Apologies to you Thomas, and the rest of the 6wind list. He just explained > to me that patch applications ni 1.6.0r2 aren't inherited by 1.7.0 so the > entire patch series will need to be reapplied to 1.7.0. Sorry, you misunderstood :) I'm starting a master branch from 1.6.0r2. So the rest of you serie will be applied on master branch where 1.7.0 is going to live. I won't split patch serie anymore. Apologies for the confusion. -- Thomas