Re: Forcing static link of libstdc++

2006-09-26 Thread Stefan Puiu
Hi Mike, I've just had the 'pleasure' to deal with the limitations of Flash 7 on Linux, so I would say I'm quite interested in version 9 coming out as soon as possible. That's why this might sound off topic. I also think Ralf's suggestion about parallel versions for libstdc++.so.5 and

Re: Forcing static link of libstdc++

2006-09-26 Thread Stefan Puiu
(posting this to the list, too) Hi, I'm actually glad you replied. On 9/26/06, Mike Melanson [EMAIL PROTECTED] wrote: 1) Having 2 binaries would immediately double the QA effort. Yes, but also making sure the flash plugin can statically link with libstdc++ increased your development effort

Re: Forcing static link of libstdc++

2006-09-26 Thread Stefan Puiu
On 9/26/06, Mike Melanson [EMAIL PROTECTED] wrote: The QA process is exactly doubled since there are 2 binaries instead of 1 binary that needs to be run through the formal certification process. I understand that very well. I was just thinking that it might be preferrable than dealing with

Re: redirecting produced files

2006-08-28 Thread Stefan Puiu
Hi, I'm by no means an autotools expert, but there's a simple way to achieve something somewhat similar to what you want. You could run 'autoreconf -fvi' in your source directory, and then, depending on your arch/configuration, you can type: cd ../../bin/[os]/[compiler]/[debug/release]

Re: Non-recursive makefiles

2006-06-06 Thread Stefan Puiu
Hi, On 6/6/06, Ralf Corsepius [EMAIL PROTECTED] wrote: Well, that's one of those cases I'd prefer to call urban legends of flat makefiles. Yes, in an ideal world, a flat makefile can take all dependencies. But in real world a complex package consists of more or less independent subpackages, or

Re: Non-recursive makefiles

2006-05-28 Thread Stefan Puiu
HI all, I find some of the information in this thread quite useful, especially since I was considering to move some of our project files to non-recursive makefiles. I understand the downsides - silly variable names in subdir makefiles, which are also tied to the respective directory and require

Re: LDADD and linker options like --whole-archive

2006-04-21 Thread Stefan Puiu
Hi Marc, thanks a lot for your assistance. Now I think I understand the point. It seems like a good solution for the future, however, I don't have the time to try this right now, and in the short term it doesn't seem to bring significant improvements, besides allowing me to get rid of

Re: LDADD and linker options like --whole-archive

2006-04-20 Thread Stefan Puiu
Hi Marc, what can I say, on one hand you've made me curious about this option. We're also experiencing long linking times (well, nothing compared to the old project you mentioned), but still, 4 minutes for linking in one modified library is a bit much. Unfortunately, we're not using libtool yet.

Re: LDADD and linker options like --whole-archive

2006-04-20 Thread Stefan Puiu
Hi and thanks for replying, On 4/19/06, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Stefan, Have you ever considered using Libtool? Its convenience archives would be a portable alternative to --whole-archive. I'm not that familiar with libtool. And you have to bear in mind that for most

LDADD and linker options like --whole-archive

2006-04-19 Thread Stefan Puiu
Hi, I was considering to file this as a bug report, but I thought I'd first check on the list first. Sorry if this was already brought up (there's also a bug report which is somewhat similar to my problem - automake PR number 55). So, my problem is that for some reason in our projects some