Re: ommoncpp2.1.8.1 build with c++ c17 does not work

Matthew, They are not maintained anymore. Last time I did some work on libcomoncpp2 was was 4 years ago. I’d suggest to give ucommon a try as they are more recent than libcommoncpp2. If you like to work on multiple platform I’d suggest to use build.opensuse.org to ho

Re: Release 7.0.1

I probably should have started it as a rc branch, especially given the large number of changes that ended up going in already, but I made one now. I did not want to change api/interfaces in 7.0.1, but yes, we should at least check openssl/gnutls return codes, and the exception stuff does need to b

Re: Release 7.0.1

On Sun, Sep 20, 2020 at 11:55 AM David Sugar wrote: > > I think I have all the changes needed for a 7.0.1 release in now. > > I did bring in some downstream patches from Debian, and minimally fixed > support for openssl 1.1. A lot of the rest was code cleanup and a few small > bug fixes, as well

Re: Is commoncpp and ucommon still being maintained?

On Wed, Jul 22, 2020 at 9:56 AM Jeffrey Walton wrote: > On Wed, Jul 22, 2020 at 9:45 AM Stefano Canepa wrote: > > On Wed, 2020-07-22 at 09:25 -0400, Jeffrey Walton wrote: > > > Hello, > > > > > > Is commoncpp and ucommon still being maintained? > > > ... > > as far as I know they are not maintain

Re: Is commoncpp and ucommon still being maintained?

On Wed, Jul 22, 2020 at 9:45 AM Stefano Canepa wrote: > > On Wed, 2020-07-22 at 09:25 -0400, Jeffrey Walton wrote: > > Hello, > > > > Is commoncpp and ucommon still being maintained? > > ... > as far as I know they are not maintained any more. I made commoncpp > compiling on latest g++ as someone

Re: Is commoncpp and ucommon still being maintained?

On Wed, 2020-07-22 at 09:25 -0400, Jeffrey Walton wrote: > Hello, > > Is commoncpp and ucommon still being maintained? > > If it is not maintained, then I would like to start the process of > taking temporary maintainership to fix some compile errors. I have > already reached out to the FSF and l

Re: Possible Bug when building commoncpp

On Tue, Apr 28, 2020 at 09:31:10PM +0200, Maximilian Barger wrote: > I've recently tried to install commoncpp2 from source and I was unable > due to a compilation error. This error has appeared in every version > I've tried so far. This issue has been resolved in Debian[1]; you might want to apply

Re: Possible Bug when building commoncpp

On Tue, 2020-04-28 at 21:31 +0200, Maximilian Barger wrote: > Hi! > > I've recently tried to install commoncpp2 from source and I was > unable > due to a compilation error. This error has appeared in every version > I've tried so far. > > I have attached the error message when compiling commoncpp

Re: Bug found in src/applog.cc in commoncpp2-1.8.1

Ok. Good to know. On Tue, Jul 18, 2017, 12:22 PM Stefano Canepa wrote: > IIRC there is a patch in RH and SUSE package for this as we were not > allowed to commit to the project. > > > Stefano Canepa > s...@linux.it or stef...@canepa.ge.it > > On 18 Jul 2017 5:13 pm, "Charlie Sale" wrote: > >> I

Re: Bug found in src/applog.cc in commoncpp2-1.8.1

IIRC there is a patch in RH and SUSE package for this as we were not allowed to commit to the project. Stefano Canepa s...@linux.it or stef...@canepa.ge.it On 18 Jul 2017 5:13 pm, "Charlie Sale" wrote: > I compiled with standard autoconf/automake procedure. I ran: > > $ ./configure --prefix=/us

Re: Bug found in src/applog.cc in commoncpp2-1.8.1

I compiled with standard autoconf/automake procedure. I ran: $ ./configure --prefix=/usr/local $ make $ make install The build failed during make. It said that each permission bit could not be found and recommended prefixing each one with '__'. I checked the file and noticed that the file was no

Re: Bug found in src/applog.cc in commoncpp2-1.8.1

Charlie, how did you install commoncpp2? On 18 July 2017 at 03:23, Charlie Sale wrote: > During compilation, all permission bits were not defined in scope. > Add `#include ` to the file to fix the bug. I did so and it > fixed the > problem. Thanks > -- > > ~Charlie Sale > >

Re: OS X Compile Bug

I was able to qa the string patch sfl is using sufficiently to include in the next release... On Monday, September 01, 2014 04:55:19 PM Tristan Matthews wrote: > Hi, > > - Original Message - > > > From: "Dominyk Tiller" > > To: bug-commoncpp@gnu.org > > Sent: Sunday, August 31, 2014 8:

Re: OS X Compile Bug

The first we already seem to already have in the current and/or for the next release. I think there has always been some confusion about the role of UCOMMON_EXTENDED and what we were doing for facilitating special case builds for deeply embedded services, such as putting sipwitch onto routers.

Re: OS X Compile Bug

Hi, - Original Message - > From: "Dominyk Tiller" > To: bug-commoncpp@gnu.org > Sent: Sunday, August 31, 2014 8:24:24 AM > Subject: OS X Compile Bug > > Hey guys, > > I'm hitting some issues compiling ucommon-6.1.10 on OS X. I'm running > 10.10, but the build fails even when I use gcc r

Re: build of ucommon-5.2.2 fails

Please confirm with 5.5.0 and/or 6.0.0. I believe all original bsd build issues were closed by 5.5.0, and 6.0.0 has also been tested with and fixed for clang. On 11/11/2012 08:57 AM, oth...@safetymail.info wrote: > You guys have always been helpful in resolving issues with the GNU Telephony > pac

Re: "gaurd" typo

and I would love to see it adopt srtp and zrtp. On 04/05/2012 12:11 PM, Tristan Matthews wrote: > - Original Message - >> From: "David Sugar" >> To: bug-commoncpp@gnu.org >> Sent: Wednesday, April 4, 2012 2:10:58 PM >> Subject: Re: "gaurd"

Re: "gaurd" typo

- Original Message - > From: "David Sugar" > To: "Tristan Matthews" > Cc: bug-commoncpp@gnu.org > Sent: Thursday, April 5, 2012 4:03:46 PM > Subject: Re: "gaurd" typo > > > >> I do recall sflphone and I would love to see i

Re: "gaurd" typo

>> I do recall sflphone and I would love to see it adopt srtp and zrtp. > > We do currently support srtp and zrtp, albeit with an older version of ccrtp. Very cool, and I did not know At the very least we (I mean as in GNU Telephony) should be mentioning it... _

Re: "gaurd" typo

- Original Message - > From: "David Sugar" > To: "Tristan Matthews" > Cc: bug-commoncpp@gnu.org > Sent: Thursday, April 5, 2012 12:30:21 PM > Subject: Re: "gaurd" typo > > Since the commoncpp layer is kept separate specifically for &

Re: "gaurd" typo

- Original Message - > From: "David Sugar" > To: bug-commoncpp@gnu.org > Sent: Wednesday, April 4, 2012 2:10:58 PM > Subject: Re: "gaurd" typo > > I actually almost hate these kind of errors, because they nonetheless > do > touch upon linkage a

Re: "gaurd" typo

I actually almost hate these kind of errors, because they nonetheless do touch upon linkage abi. Actually it is probably a good time to consider what will become 6.0, which offers a good opportunity to also consider depreciating/changing/break other abi issues. I have thought about re

Re: SockExcpetion getSystemErrorString() method gives unexpected result

Hello list, I found the cause of my issue. It's about which variant of strerror_r is used. >From strerror_r man pages: char *strerror_r(int errnum, char *buf, size_t buflen); /* GNU-specific strerror_r() */ #define _XOPEN_SOURCE 600 #include int strerror_r(int

Re: Win7 Build Issue

I would be happy to take this patch in for the next release. I will also have to see if this applies to ucommon. I see there we currently have: #ifdef _MSWINDOWS_ unsigned Socket::pending(socket_t so) { u_long opt; if(so == INVALID_SOCKET) return 0; ioctlsocket(so, FIONREAD,

Re: HowTo for queues - open issues resolved in 3.0.1

On Sunday June 6 2010, David Sugar wrote: > I have added new create() methods to the reusable pool templates so it > can return pre-constructed (initialized) objects. I also found a bug > internal to queueof lifo method and changed the templates for queueof > and stackof so that the pool is passed

Re: HowTo for queues - open issues resolved in 3.0.1

I have added new create() methods to the reusable pool templates so it can return pre-constructed (initialized) objects. I also found a bug internal to queueof lifo method and changed the templates for queueof and stackof so that the pool is passed to the constructor rather than in the template (l

Re: HowTo for queues

On Saturday June 5 2010, David Sugar wrote: > First, the queue core class can use a reusable pool, but this is for > internal management of it's own pointers. The queue is passed an object > to post into it that is derived from "Object", which are reference > counted. Hence, existing on the queue

Re: HowTo for queues

First, the queue core class can use a reusable pool, but this is for internal management of it's own pointers. The queue is passed an object to post into it that is derived from "Object", which are reference counted. Hence, existing on the queue is actually a reference count instance of a referen

Re: HowTo for queues

Thank you David. I shall be really glad if you will be able to give me the list of classes to be used for the following simple task: Two threads A and B. A receives data from somewhere into buffers (of the same size) polled from buffer pool (which classes?). Then A sends these buffers to B (whi

Re: HowTo for queues

The queue class was written because there are some older Bayonne drivers that would likely make use of it when the rest of Bayonne is ported to ucommon, and it is also based on some stuff also used in the original Common C++. However, those drivers (in particular, Dialogic and Pika, which used an

Re: [Bayonne-devel] call c++ method by string name + passing parameters

gafferuk wrote: > > > > gafferuk wrote: >> >> Im trying to create my own scripting engine/language. >> >> Is it possible to call a c++ class method by string name and also pass in >> the parameters? >> >> for example I have a class called MyClass with a method called callme: >> >> bool My

Re: [Bayonne-devel] call c++ method by string name + passing parameters

gafferuk wrote: > > Im trying to create my own scripting engine/language. > > Is it possible to call a c++ class method by string name and also pass in > the parameters? > > for example I have a class called MyClass with a method called callme: > > bool MyClass::callme(string name) > { >

Re: TCPtream bug

Connected()) > { > ::usleep(100*3); > continue; > } > } > > Once the first run in connect() failed, it will keep connecting to > indicated IP and port > but the 2nd time it connect, will cause the socket error (I print out > the errno) > > I found the

Re: commoncpp2-1.6.2 vs. Sparc Solaris (9/10)

Maybe this can be wrapped in a configure library test to make sure there really is a "clock_nanosleep()" to link with? I should see if this is relevant to ucommon as well... Reinhard Drube wrote: > for Solaris one need a change in > > src/timer.cpp: > > 130,131c130 > < // ::clock_nanoslee

Re: Common c++ Thread::notify implementation question.

When a new thread is created, it records the thread instance it was created from, and this becomes the "parent" reference. However, using notify requires that the parent does not dissapear (get deleted) before it's child, and requires tracking of thread meta data. For these reasons, I actuall

Re: Where to go to ask questions?

At the moment I am working on merging the ucommon & gnu common c++ codebases into a single core library which has the advantages of both, as well as greatly reducing complexity for IPV6 addressing support, and this is anticipated to become GNU Common C++ 2 "2.0" perhaps as early as June. Conr

RE: Where to go to ask questions?

The project's founder David Sugar http://savannah.gnu.org/users/dyfet has migrated the project's home from time to time which means you'll find it and the code in multiple locations; for example: http://sourceforge.net/projects/cplusplus/ http://www.gnutelephony.org/index.php?title=GNU_Common_C%2

Re: Is anyone still there?

Conrad T. Pino schreef: You can see if your original message was processed by visiting the bug-commoncpp mailing list archive page: http://lists.gnu.org/archive/html/bug-commoncpp/ and following one or more monthly links depending on when sent. If it's archived then resending it is pointless.

RE: Is anyone still there?

You can see if your original message was processed by visiting the bug-commoncpp mailing list archive page: http://lists.gnu.org/archive/html/bug-commoncpp/ and following one or more monthly links depending on when sent. If it's archived then resending it is pointless. -Original Message-

Re: Please don't use the address Bug-commoncpp@gnu.org, please change your addressbook.

Hi, Are you by any chance the one who is responsible for the message below? Because it directs me to a site telling me to send mail to someones first name dot lastname. The site is signed Tobias, but nowhere does it say what his lastname is. I found yours by searching for Tobias at profzone.c

RE: Installing GCC on Solaris 10 Intel server

This topic is not appropriate for this list: bug-commoncpp@gnu.org This message is probably stale for Solaris 10 but identifies a better list: http://gcc.gnu.org/ml/gcc/1999-08n/msg01022.html This page is probably current but is terse: http://gcc.gnu.org/install/specific.html Click on "i?86-*-sol

Re: Class Keydata - similar entries from multiple sections?

Normally you would load each [] into a different keydata object. If you merge keydata sections into a single object instance, there is no means to determine which instance it was loaded under. Mostly merging is meant to load "default" keys into a given object, and then override them with live val

Re: Daemons - Using the process class?

What attach does is dissasociate the controlling terminal and potentially associate with a new one under a new process group. The same code is reused for detach, which does the dissociate and single fork on some platforms, and a dual fork on others. Wolfgang Alper wrote: > Hello, > > Sorry, i ju

Re: binary data transmit with TCPStream

Wakan schrieb: > I'm sending binary data over a socket connection using TCPStream. > I'm using: >tcp.write(row[3],tpl_size); >tcp << endl; > where row[3] contains binary data. ... > In which way can I resolve that problem? How can I transmit in secure > way binary

Re: Daemons - Using the process class?

Hello, Sorry, i just realized that the following is obviously wrong: > but this cannot work as it is defined as follows: > void Process::detach(void) { attach("/dev/null"); } This calls attach with "dev/null". Anyway, i still do not get it to work so any help is apprecicated. Example: main()

Re: binary data transmit with TCPStream

Wakan schrieb: > I'm sending binary data over a socket connection using TCPStream. > I'm using: >tcp.write(row[3],tpl_size); >tcp << endl; > where row[3] contains binary data. ... > In which way can I resolve that problem? How can I transmit in secure > way binary

Re: can't release mutex

I'm afraid of semaphores don't resolve my problem... What about Conditional? How to use it? Have you got some suggestions on how to implement the "time sharing" with commoncpp instruments? Carlo David Sugar ha scritto: No, any OTHER thread that would have blocked on that lock will continu

Re: can't release mutex

No, any OTHER thread that would have blocked on that lock will continue after the timeout...so if you are using a common lock, you want another thread to hit it, and use the wait to enter, as it can then see if the lock got stuck, while your processing thread does so without a timeout Wakan w

Re: can't release mutex

OK David, first of all thanks for your precious help... only a clarifying question (clarifying for me of course... :)): when the library function execution exceeds the timeout value, the piece of code in: if(!semimutex.wait(timeout)) { --> library must have crashed, etc... } ru

Re: can't release mutex

What you are thinking of is something like this: Semaphore semimutex(1); ... if(isPending(pendingInput)) { if(!semimutex.wait(timeout)) { library must have crashed, etc... } call library function ...

Re: can't release mutex

Thanks for your reply. Can you write an example with the semaphore in this context? Thanks, Carlo Wakan ha scritto: Thanks for your reply. Can you write an example with the semaphore in this context? Thanks, Carlo David Sugar ha scritto: I think what he really wants to do is use

Re: can't release mutex

Thanks for your reply. Can you write an example with the semaphore in this context? Thanks, Carlo David Sugar ha scritto: I think what he really wants to do is use the Common C++ Semaphore with a count of 1, since semaphore can block with a "timeout", and with a "1" count in effect acts as

Re: commoncpp 1.5.0 doesn't build with fstack-protector

I will see if this is still true with 1.5.5... Alan Mizrahi wrote: > Hello, > > Unfortunately commoncpp2-1.5.0 doesn't build when using -fstack-protector gcc > flags. > The stack protector flags are supported in gcc 4.1.1, could you verify this? > > Regards, > begin:vcard fn:David Sugar n:Suga

Re: libcommoncpp2-1.5-0 version 1.5.3-1 is ABI incompatible with version 1.5.1-4

ick...we should have changed the abi rev level then...it got missed... Mark Purcell wrote: > David, > > It would appear that commoncpp2-1.5.3 isn't ABI compatible with previous > releases due to changes with ost::Thread::isRunning > > http://bugs.debian.org/402009 > > Mark > > -- Fo

Re: Fwd: Bug#399482: libcommoncpp2: build process cannot find ldconfig

This was already removed in 1.5.3... Mark Purcell wrote: > David, > > I have received a report about your install-local-data rule in libcommoncpp2. > > Apparently you have made some assumptions about the target directory, which > isn't always correct. > > The full bug report is available at ht

Re: Fwd: Bug#352123: libcommoncpp2-dev: slog should not cut after 128 bytes

This will break abi, so I will do it for a new 1.6 release set... Mark Purcell wrote: > > -- Forwarded Message -- > > Subject: Fwd: Bug#352123: libcommoncpp2-dev: slog should not cut after 128 > bytes > Date: Friday 10 February 2006 11:07 > From: Mark Purcell <[EMAIL PROTECTED

Re: can't release mutex

I think what he really wants to do is use the Common C++ Semaphore with a count of 1, since semaphore can block with a "timeout", and with a "1" count in effect acts as a mutex... The larger question though of what to do with the stuck thread, perhaps from a broken library, is important also. He

Re: can't release mutex

Thanks very much for your kind reply! I think the problem is elsewhere... When the thread the calls the proprietary function never runs to the mutex.leaveMutex(), say because the function doesn't be able to exit for an internal break, all other threads will continue to loop in vainbecause

RE: can't release mutex

You're on the right track. Please pardon my rusty recollection syntax. Revise: mutex.enterMutex(); to a form that accepts a timeout. This example won't compile: const int timeout = 500; while (1) { if ( isPending( pendingInput ) ) {

RE: C++ exceptions in persistent streams (patch!)

Well then. I guess there is nothing to be done at this point then. Thanks much, Erik. > -Original Message- > From: David Sugar [mailto:[EMAIL PROTECTED] > Sent: Monday, February 13, 2006 3:47 PM > To: Ohrnberger, Erik > Cc: bug-commoncpp@gnu.org > Subject: Re:

Re: C++ exceptions in persistent streams (patch!)

onday, February 13, 2006 1:42 PM To: Ohrnberger, Erik Cc: bug-commoncpp@gnu.org Subject: Re: C++ exceptions in persistent streams (patch!) Having thought about it, you are right, they should be "PersistException". This is most consistent with other parts. [EMAIL P

Re: C++ exceptions in persistent streams (patch!)

4 PM To: Ohrnberger, Erik Cc: bug-commoncpp@gnu.org Subject: Re: C++ exceptions in persistent streams (patch!) Originally persist had a completely different exception system of it's own at a time that Common C++ did not have a standardized exception model, as the code has separate orig

RE: C++ exceptions in persistent streams (patch!)

t; Cc: bug-commoncpp@gnu.org > Subject: Re: C++ exceptions in persistent streams (patch!) > > > Having thought about it, you are right, they should be > "PersistException". This is most consistent with other parts. > > [EMAIL PROTECTED] wrote: . . . . __

Re: UDPBroadcast

Well I resently downloaded/compiled/linked common c++ 2-1.3.23, and the latter problem seems to be fixed (I use VC6) Mr.G -- View this message in context: http://www.nabble.com/UDPBroadcast-t1067937.html#a2908517 Sent from the Gnu - Common C++ forum at Nabble.com.

RE: C++ exceptions in persistent streams (patch!)

urces and patch file providing. Erik. > -Original Message- > From: David Sugar [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 12, 2006 4:04 PM > To: Ohrnberger, Erik > Cc: bug-commoncpp@gnu.org > Subject: Re: C++ exceptions in persistent streams (patch!) > >

Re: C++ exceptions in persistent streams (patch!)

Originally persist had a completely different exception system of it's own at a time that Common C++ did not have a standardized exception model, as the code has separate origin. I you are correct that it should be consolidated for consistency. This was probably overlooked when that was initi

RE: C++ exceptions in persistent streams (patch!)

While reviewing the code in engine.cpp, I noticed that there were multiple types of exceptions: ost::Exceptions | V ost::PersistException | V ost::Engine::Exception It seems to be that Engine::Engine is the on

RE: C++ exceptions in persistent streams (patch!)

Please find attached two patch files. They are for: * commoncpp2-1.3.1/include/cc++/persist.h and * commoncpp2-1.3.1/src/engine.cpp This patch will apply changes needed to make the void Engine::readObject(BaseObject* object) THROWS( Engine::Exception ) throw the i

RE: C++ exceptions in persistent streams

OK, so nobody responded. OK. Figured it out for myself. You have to enable the stream library exception mechanism using the fstream.exceptions( ) method to do so. Well, at least you get std::exceptions at that point. I've never seen the PersistException or Exception (Engine::Exception) ever

Re: Are these bugs of commoncpp on win32 platform?

Some may have been related to behaviors found originally in much older platform sdk's and never updated... INADDR_NONE is usually used to "disconnect" the socket from any active connection. But if setting broadcast is nessisary, then certainly it can be done. However, then the socket may be

Re:

The other config.h is generated from configure.ac, so really then these defines should migrate into something emitted from configure.ac...perhaps wrapped in a #ifdef WIN32 block Holger Tasch wrote: Hello List, a problem occured while trying to build commoncpp2-1.3.19 in MSYS with MINGW (a

RE: Patch: Microsoft *.dsp Build Files - Debug Libraries

Hi David, > From: David Sugar > Sent: Thursday, September 01, 2005 05:23 > > Hmm...I think I removed the d naming so that later one could substitute > the debug version for testing of an app by changing the PATH, without > having to use a different link name. This was otherwise causing all >

Re: Patch: Microsoft *.dsp Build Files - Debug Libraries

Hmm...I think I removed the d naming so that later one could substitute the debug version for testing of an app by changing the PATH, without having to use a different link name. This was otherwise causing all sorts of headaches in Bayonne's w32 build and testing because I could not directly s

Re: Microsoft w32/tests/*.dsp Projects Question

They probably do belong in common. And yes, it will be much more convenient having them there than having to pick and choose the individual project file. Conrad T. Pino wrote: The end of this messages contains a patch implementing Option #1. This patch is not committed as yet. The build outp

RE: Microsoft w32/tests/*.dsp Projects Question

The end of this messages contains a patch implementing Option #1. This patch is not committed as yet. The build output look like: H:\commoncpp2>dir w32\Debug\*.exe w32\Release\*.exe Volume in drive H is CTP-RAID-001 Volume Serial Number is 6897-6A9D Directory of H:\commoncpp2\w32\Debug 08/31

RE: Linux Builds Complete - Questions

Hi David, > From: David Sugar > Sent: Wednesday, August 31, 2005 07:20 > To: Conrad T. Pino > Cc: [EMAIL PROTECTED]; Bug Common C++ > Subject: Re: Linux Builds Complete - Questions > > At one time, when machine speeds were still measured in mghz, and g++ > was still rath

Re: Linux Builds Complete - Questions

At one time, when machine speeds were still measured in mghz, and g++ was still rather slow to compile, this was done to save on time waiting for the package to build. After all, nobody building just to install wanted to also wait to build the demos and test programs they were not using. To m

RE: Linux Builds Complete - Questions

Hi David, > From: David Sugar > Sent: Tuesday, August 30, 2005 04:37 > > There is a configure option --without-compression, which gets rid of the > need for libz. There is also --without-libxml2. If your not using > exceptions, you might want to use --without-exceptions as well... IMO these t

Re: Linux Builds Complete - Questions

There is a configure option --without-compression, which gets rid of the need for libz. There is also --without-libxml2. If your not using exceptions, you might want to use --without-exceptions as well... All you really need to do is make sure the resulting arm libcc* files are on a valid li

RE: Patch: Windows Platform SDK - IPv6 - Borland C++ Builder 6.0 -Windows 2000

Hi David, > From: David Sugar [mailto:[EMAIL PROTECTED] > Sent: Monday, August 29, 2005 22:50 > > Build Bayonne? :)...The individual demos and test programs generally > should be buildable and are fairly easy to follow. Even the current > tests don't act as a full or complete regression, but t

Re: Patch: Windows Platform SDK - IPv6 - Borland C++ Builder 6.0 -Windows 2000

Build Bayonne? :)...The individual demos and test programs generally should be buildable and are fairly easy to follow. Even the current tests don't act as a full or complete regression, but they should give a generally good idea of whether is something important is broken fairly quickly. Co

RE: Patch: Windows Platform SDK - IPv6 - Borland C++ Builder 6.0 -Windows 2000

Hi David, > From: David Sugar > Sent: Monday, August 29, 2005 21:50 > > The other question to confirm is whether something links with it (such > as the demo apps). That is where interesting things could be quickly > identified, particularly I find in the windows builds on anything that > effe

RE: Patch: Windows Platform SDK - IPv6 - Borland C++ Builder 6.0 -Windows 2000

Hi David, > From: Conrad T. Pino > Sent: Monday, August 29, 2005 11:38 > > > From: David Sugar > > Sent: Monday, August 29, 2005 07:48 > > > > This may be readyI was actually looking for something to consider > > for a point release today since I am also doing a new cape build, and > > res

Re: Patch: Windows Platform SDK - IPv6 - Borland C++ Builder 6.0 -Windows 2000

The other question to confirm is whether something links with it (such as the demo apps). That is where interesting things could be quickly identified, particularly I find in the windows builds on anything that effects platform sdk versions. Conrad T. Pino wrote: Hi David, From: Conrad T.

RE: No "configure" script in CVS?

Hi David, > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Sugar > Sent: Monday, August 29, 2005 16:35 > To: Conrad T. Pino > Cc: [EMAIL PROTECTED]; Bug Common C++ > Subject: Re: No "configure" script in CVS?

Re: No "configure" script in CVS?

Debian package system. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Sugar Sent: Monday, August 29, 2005 13:32 To: Conrad T. Pino Cc: Bug Common C++ Subject: Re: No "configure" script in CVS? configure is generated in a cvs

Re: ./reconfig message: add libtool.m4 to aclocal.m4

A later step in reconfig automatically rebuilds aclocal.m4. You can ignore that message. Conrad T. Pino wrote: When I run "./reconfig" immediately after a CVS checkout I get this message: You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'. A subsequent run in the

RE: No "configure" script in CVS?

Sent: Monday, August 29, 2005 13:32 > To: Conrad T. Pino > Cc: Bug Common C++ > Subject: Re: No "configure" script in CVS? > > configure is generated in a cvs checkout from ./reconfig ___ Bug-commoncpp mailing list Bug-comm

Re: No "configure" script in CVS?

configure is generated in a cvs checkout from ./reconfig Conrad T. Pino wrote: Hi David, There is no "configure" script in the CVS archive. How do I bring one into existence on Linux 2.6? Conrad begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony adr:;;USA email;internet:[EMAIL PR

RE: Patch: Windows Platform SDK - IPv6 - Borland C++ Builder 6.0 - Windows 2000

Hi David, > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Sugar > Sent: Monday, August 29, 2005 07:48 > To: Conrad T. Pino > Cc: [EMAIL PROTECTED]; Bug Common C++ > Subject: Re: Patch: Windows Platform SDK - IPv6 - B

Re: Patch: Windows Platform SDK - IPv6 - Borland C++ Builder 6.0 - Windows 2000

. Pino Cc: Bug Common C++ Subject: Re: Windows Platform SDK - IPv6 - Borland C++ Builder 6.0 - Windows 2000 Yes, ipv6 and platformsdk have an odd entanglement at the moment. The default I choose, actually, of having platformsdk defined, was in large part because this matched what osip/exosip

RE: Win32 - Borland C++ Builder 6.0 Compiles Fails

Hi David, > From: David Sugar > Sent: Thursday, August 25, 2005 05:05 > To: Conrad T. Pino > Cc: Bug Common C++ > Subject: Re: Win32 - Borland C++ Builder 6.0 Compiles Fails > > This sounds good too! I know we had in the past a few people using bcc, > which is where

Re: Windows Platform SDK - IPv6 - Borland C++ Builder 6.0 - Windows 2000

, -Original Message- From: David Sugar Sent: Thursday, August 25, 2005 04:48 To: Conrad T. Pino Cc: Bug Common C++ Subject: Re: ccgnu2 - Win32 Microsoft Compiler Warnings I had wondered if there was a more elegant way of handling the platform sdk version, as it seems the older and newer sdk

Re: Compile Error: Windows 2000 - Visual C++ 6 - No Platform SDK - Other build Environments

Not at all. I simply have not tested with vc6 without the later platform sdk's for so very long that it is quite possible it is now broken. This sounds like a useful patch. Conrad T. Pino wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I presume it's well known the HEAD revision does

Re: ccgnu2 - Win32 Microsoft Compiler Warnings

I had wondered if there was a more elegant way of handling the platform sdk version, as it seems the older and newer sdk have mutually exclusive requirements for the ordering of header files...for the moment the distribution assumes the newer sdk is installed by default. Conrad T. Pino wrote:

Re: Win32 - Borland C++ Builder 6.0 Compiles Fails

This sounds good too! I know we had in the past a few people using bcc, which is where the Makefile for Borland originally came from, but they had not submitted updates in recent times. I do think supporting many different compilers (beyond gcc) is very useful as a matter of principle as each

Re: Current CVS Repository Location

ednesday, August 24, 2005 17:48 To: Conrad T. Pino Cc: Bug Common C++ Subject: Re: Current CVS Repository Location Currently we are using the sourceforge one. This was because I could consolidate all my work and all the packages where I am the primary or only person currently doing active change

RE: Current CVS Repository Location

ay, August 24, 2005 17:48 > To: Conrad T. Pino > Cc: Bug Common C++ > Subject: Re: Current CVS Repository Location > > Currently we are using the sourceforge one. This was because I could > consolidate all my work and all the packages where I am the primary or > only pers

Re: Current CVS Repository Location

Currently we are using the sourceforge one. This was because I could consolidate all my work and all the packages where I am the primary or only person currently doing active changes in just one place under one repository. The one exception is ccrtp, which is also very activily maintained by

RE: Current CVS Repository Location

Oops, I forgot, there is also the cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/commoncpp co commoncpp2 which was offical in May 2004 according to http://lists.gnu.org/archive/html/bug-commoncpp/2004-05/msg00018.html > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Beh

  1   2   >