Go to Post There's nothing wrong with taking suggestions but be sure not to let other people tell you how your team should be run. - NickE [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 6 votes, 5.00 average. Display Modes
  #61   Spotlight this post!  
Unread 14-01-2013, 06:21
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Unfortunately I can't find a way to get C++11 to work either. I remembered it working a while ago however this does not appear to be the case.

I'll send a message to gcc-help asking about this.

Redefine __cplusplus to 201103L at the top of your source file and watch the barf spew from the compiler...
  #62   Spotlight this post!  
Unread 15-01-2013, 08:44
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

OK, I've determined the cause of the c++11 failures - turns out it was my own stupidity.

I have classes so I don't have time to regen the packages until this weekend, but the quick fix is to go into /usr/powerpc-wrs-vxworks/share/cmake/toolchain.cmake, look for the line containing -ansi, and remove -ansi from that line. Then, when you call cmake, use:

Code:
$ frcmake $SRCDIR -DCMAKE_CXX_FLAGS='-std=c++11 -fpermissive'
I don't want to make this default yet as there's still a few issues in WPILib with C++11 compatibility and I don't want to mess up people who are happy with c++98
  #63   Spotlight this post!  
Unread 15-01-2013, 14:49
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by rbmj View Post
OK, I've determined the cause of the c++11 failures - turns out it was my own stupidity.

I have classes so I don't have time to regen the packages until this weekend, but the quick fix is to go into /usr/powerpc-wrs-vxworks/share/cmake/toolchain.cmake, look for the line containing -ansi, and remove -ansi from that line. Then, when you call cmake, use:

Code:
$ frcmake $SRCDIR -DCMAKE_CXX_FLAGS='-std=c++11 -fpermissive'
I don't want to make this default yet as there's still a few issues in WPILib with C++11 compatibility and I don't want to mess up people who are happy with c++98
Would you mind giving a few details on whats up with WPILib and C++11 so I can either work the problems out or avoid situations in which they would be a problem?
  #64   Spotlight this post!  
Unread 15-01-2013, 15:37
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

The biggest thing is that GCC seems to conform to the standard more strictly in c++11 mode than in c++98 mode. In C++98 mode it is technically wrong to declare and initialize a static constant of non-integral type in a header file, however gcc accepts it. However, with c++11 and the constexpr keyword there is an easy workaround so gcc wants you to use constexpr instead of const. This causes compile errors, though these can be downgraded to warnings with the -fpermissive flag. However, I feel uncomfortable adding this flag in as I believe that code should conform to the standard and be warning-free. Although in some cases these are merely stylistic concerns, I think that in many cases these can highlight a bug or undefined behavior. This is why I enable -Wall in the toolchain file.

I'm working on cleaning up the WPILib headers so that they won't fire off warnings. This way they don't fill up the build log for the end user. Library headers that fire warnings are at best annoying and at worst can overwhelm valuable output from the compiler.
  #65   Spotlight this post!  
Unread 16-01-2013, 00:06
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by rbmj View Post
The biggest thing is that GCC seems to conform to the standard more strictly in c++11 mode than in c++98 mode. In C++98 mode it is technically wrong to declare and initialize a static constant of non-integral type in a header file, however gcc accepts it. However, with c++11 and the constexpr keyword there is an easy workaround so gcc wants you to use constexpr instead of const. This causes compile errors, though these can be downgraded to warnings with the -fpermissive flag. However, I feel uncomfortable adding this flag in as I believe that code should conform to the standard and be warning-free. Although in some cases these are merely stylistic concerns, I think that in many cases these can highlight a bug or undefined behavior. This is why I enable -Wall in the toolchain file.

I'm working on cleaning up the WPILib headers so that they won't fire off warnings. This way they don't fill up the build log for the end user. Library headers that fire warnings are at best annoying and at worst can overwhelm valuable output from the compiler.
Cool. I'll probably join in on working with WPILib. Who knows, we might find a bug! The java version actually had a sine and cosine flipped two years ago.
  #66   Spotlight this post!  
Unread 16-01-2013, 06:04
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Beat you to it:

http://firstforge.wpi.edu/sf/go/artf...=1358334177246

  #67   Spotlight this post!  
Unread 16-01-2013, 17:45
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Hi there! I've been reluctant to install via the packages due to my infinitely small understanding of aptitude packages. I've installed the new build scripts though since there are updates to the toolchain file in there. I just installed with the following commands after checking out the powerpc-wrs-vxworks-buildscripts repo.
Code:
cmake .
make && sudo make install
The new ld script that the toolchain file now references for non-gccdist toolchains doesn't appear to be in my compiler installation. Is there somewhere where I should be getting it, or is installed by a package?

Also: should I just switch to the packages, even if I'm planning on actively developing if I find a bug/missing feature?
  #68   Spotlight this post!  
Unread 16-01-2013, 18:13
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

The link script is generated by the wrs-headers-installer package. I was not sure which package it would be more suitable in, and I ended up picking the wrs-headers-installer package, since that handles all the other proprietary information.
  #69   Spotlight this post!  
Unread 16-01-2013, 18:19
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Thanks. I need to do some reading on how aptitude packages work from a non-user perspective. Since I have a meeting tonight, and kinda want to toy with C++11 and wpilib, would you mind just giving me a quick instruction on how to build the packages? (I can install them and all that jazz, but I haven't really developed with aptitude before).

Thanks again for the patience and your awesome contributions to FIRST.

BEGIN EDIT

Just tried building GCC on my debian machine from source. I've gotten a pretty odd error. Might a recent commit have broken something?

Code:
../../../gcc-master/libgcc/libgcov.c: In function 'create_file_directory':
../../../gcc-master/libgcc/libgcov.c:143:13: error: too many arguments to function 'mkdir'
             && mkdir (filename, 0755) == -1
             ^
In file included from ../../../gcc-master/libgcc/libgcov.c:82:0:
/usr/local/powerpc-wrs-vxworks/wind_base/target/h/sys/stat.h:169:24: note: declared here
 extern    STATUS       mkdir (const char *_dirName);
                        ^
make[2]: *** [_gcov.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/mcoffin/gcc-build/powerpc-wrs-vxworks/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/mcoffin/gcc-build'
make: *** [all] Error 2

Last edited by CodeYeti : 16-01-2013 at 19:02.
  #70   Spotlight this post!  
Unread 16-01-2013, 19:21
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Sorry for the double post, but my edit button went away. Anyways, I've started fixing up wpilib to fit GCC's idea of the C++11 standard. It's in a branch called cxx11 in my fork of your wpilib repository.

http://github.com/mcoffin/wpilib
  #71   Spotlight this post!  
Unread 16-01-2013, 20:39
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Once you have debhelper and devscripts et al installed, it's not too bad. You won't be able to sign the packages, but everything else will work. Buildscripts is easy - just run ./debmake and it should work automatically. Beware, however, that that script will make the latest commit in the git repo, so you need to commit any changes before they will go into the package.

For the other packages, the basic workflow is this:
1. create or download/rename a pkgname_version.orig.tar.gz file. It should extract to pkgname-version.
2. extract this archive, and go into the the created source directory
3. If the source doesn't have a debian subdirectory, copy the debian subdirectory into the source from my git repo
4. run debuild -us -uc. This will create but not sign the packages. If you want to sign the packages yourself you'll need to make a key and make a new changelog entry with the dch command, making sure that the name, nickname (you might have to add this in manually), and email match EXACTLY your key's info.

note that in order to not conflict with the packages that debian will build, many of the packages are named powerpc-wrs-vxworks-name. That's what you use for package name. Additionally, these directories don't have version numbers, so you either have to rename the directory or make a new copy of the repo.

As an exception, you need to add -e WIND_BASE when you call debuild for gcc.

I highly suggest that you do your homework though. The debian buildsystem is very powerful, but it's not exactly simple, and there are a LOT of gotchas.

As far as your gcc error goes, looks like something's up with fixincludes (again). Double check to make sure that fixincludes is running, and if that doesn't work, look inside your gcc build directory (not top level, but the gcc build directory itself), find include-fixed, and look in there for sys/stat.h. Once you have determined that that file exists, look for a variadic macro for mkdir.

If that file does not exist, tell me which files do in the include-fixed directory.

EDIT: I'm looking at the way that you fixed WPILib. Good job on fixing all those constexpr issues, however we need to maintain compatibility with c++98. You probably need to test #if __cplusplus < 201103L and have a macro that selects the correct const-incantation for different versions of c++. My perspective is that we should strive for integration with upstream as much as possible (even if development is rather closed off) as I do not have or want to put in the time and energy necessary to maintain a full fork. This is why I worked so hard to get the patches merged in to GCC itself - so all those hacks were no longer necessary, and we weren't going after a moving target. And, to return to the point, there's no way that they'll accept any changes that break compatibility with c++98.

IF the community wants a more openly developed version of WPILib, OK. We can put in the work to make that happen if it's a goal (primarily meaning make it easy to integrate with ucpp and standard WindRiver. If we can react to bug reports on CD faster than upstream, then that might be a feature justifying a fork. However, as much as the long time between bugfixes and the secret development of WPILib irks me, I don't see a large enough demand to justify a fork.

Last edited by rbmj : 17-01-2013 at 15:30.
  #72   Spotlight this post!  
Unread 16-01-2013, 23:52
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

Quote:
Originally Posted by rbmj View Post
Once you have debhelper and devscripts et al installed, it's not too bad. You won't be able to sign the packages, but everything else will work. Buildscripts is easy - just run ./debmake and it should work automatically. Beware, however, that that script will make the latest commit in the git repo, so you need to commit any changes before they will go into the package.

For the other packages, the basic workflow is this:
1. create or download/rename a pkgname_version.orig.tar.gz file. It should extract to pkgname-version.
2. extract this archive, and go into the the created source directory
3. If the source doesn't have a debian subdirectory, copy the debian subdirectory into the source from my git repo
4. run [il]debuild -us -uc[/il]. This will create but not sign the packages. If you want to sign the packages yourself you'll need to make a key and make a new changelog entry with the dch command, making sure that the name, nickname (you might have to add this in manually), and email match EXACTLY your key's info.

note that in order to not conflict with the packages that debian will build, many of the packages are named powerpc-wrs-vxworks-name. That's what you use for package name. Additionally, these directories don't have version numbers, so you either have to rename the directory or make a new copy of the repo.

As an exception, you need to add [il]-e WIND_BASE[/il] when you call debuild for gcc.

I highly suggest that you do your homework though. The debian buildsystem is very powerful, but it's not exactly simple, and there are a LOT of gotchas.

As far as your gcc error goes, looks like something's up with fixincludes (again). Double check to make sure that fixincludes is running, and if that doesn't work, look inside your gcc build directory (not top level, but the gcc build directory itself), find include-fixed, and look in there for sys/stat.h. Once you have determined that that file exists, look for a variadic macro for mkdir.

If that file does not exist, tell me which files do in the include-fixed directory.

EDIT: I'm looking at the way that you fixed WPILib. Good job on fixing all those constexpr issues, however we need to maintain compatibility with c++98. You probably need to test #if __cplusplus < 201103L and have a macro that selects the correct const-incantation for different versions of c++. My perspective is that we should strive for integration with upstream as much as possible (even if development is rather closed off) as I do not have or want to put in the time and energy necessary to maintain a full fork. This is why I worked so hard to get the patches merged in to GCC itself - so all those hacks were no longer necessary, and we weren't going after a moving target. And, to return to the point, there's no way that they'll accept any changes that break compatibility with c++98.

IF the community wants a more openly developed version of WPILib, OK. We can put in the work to make that happen if it's a goal (primarily meaning make it easy to integrate with ucpp and standard WindRiver. If we can react to bug reports on CD faster than upstream, then that might be a feature justifying a fork. However, as much as the long time between bugfixes and the secret development of WPILib irks me, I don't see a large enough demand to justify a fork.
Sounds good. I'll have to get working on the compatibility issue. I've fixed all the errors, and some of the warnings for WPILib with C++11. I can confirm that at least the memory management features of C++11 work on hardware as of tonight!

The C++11 only version of WPILib is here: https://github.com/mcoffin/wpilib/tree/cxx11.

As for making sure we're backwards compatible, from what I've read, WPILib as it is shouldn't compile under C++98 either, it's just a fluke that GCC is playing loose with the standards there. Therefore, I think that when making a fix, it would be best to avoid the initialization of static constant members that are floats/doubles from within the class declaration all together. I think that the next best solution would just be to put them in the constructor? That would work on both standards, whereas the constexpr fix defining them as expressions would only work for C++11.

EDIT: The contents of include-fixed are as follows. I'm going to re-start from scratch just in case I missed a flag somewhere that caused fixincludes to mess up, but here are the contents in case I get the error again:
Code:
limits.h
README
syslimits.h
EDIT 2: To anybody that's thinking of dealing with WPILib, I suggest adding the following flag in CMAKE_CXX_FLAGS to filter out all the deprecated string literal warnings. There's no way that anybody is going to go through the whole library and convert it to using std::string unless that have absolutely no life.
Code:
-Wno-write-strings
EDIT 3: Build error was just a fluke. I have no idea what happened. Deleted my build directory, reconfigured and it worked. That was pretty stupid on my part. Sorry for the hassle on that one.

EDIT 4: The virtual destructor warnings are legit. These are abstract classes with pure abstract methods, and the classes have derived classes. This means that if a derived class were to have an explicit destructor, it wouldn't be getting called. I'll be sure to fix those warnings in the next round of fixes.

EDIT 5: The master branch on my git repository should fix many of the compiler warnings for wpilib on C++98 as well. I haven't tested compatibility with old versions of GCC yet though. I did leave some unnecessary typedef's in there because I think that they, at some point, were necessary, so WindRiver's version of GCC might still want them and I don't want to break compatibility with it. The C++11 branch has these changes pulled in as well.

Last edited by CodeYeti : 17-01-2013 at 00:51. Reason: edit #4
  #73   Spotlight this post!  
Unread 17-01-2013, 07:38
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

Quote:
Originally Posted by CodeYeti View Post
Sounds good. I'll have to get working on the compatibility issue. I've fixed all the errors, and some of the warnings for WPILib with C++11. I can confirm that at least the memory management features of C++11 work on hardware as of tonight!

The C++11 only version of WPILib is here: https://github.com/mcoffin/wpilib/tree/cxx11.

As for making sure we're backwards compatible, from what I've read, WPILib as it is shouldn't compile under C++98 either, it's just a fluke that GCC is playing loose with the standards there. Therefore, I think that when making a fix, it would be best to avoid the initialization of static constant members that are floats/doubles from within the class declaration all together. I think that the next best solution would just be to put them in the constructor? That would work on both standards, whereas the constexpr fix defining them as expressions would only work for C++11.
Ha yes, as it stands a *lot* of code shouldn't compile under C++98 either. However GCC 3.x is *very* lax with compliance. GCC 4 really stepped up on its strictness, which is great except it also causes cases like these. I think in c++98 mode there's a little more leniency built in just for backwards compatibility.

Well, if it's a static const you can:
Code:
//foo.h
class foo {
   static const float bar;
};
//foo.cpp
#include "foo.h"
const float foo::bar = 1.0;
AFAIK that will work.

Quote:

EDIT: The contents of include-fixed are as follows. I'm going to re-start from scratch just in case I missed a flag somewhere that caused fixincludes to mess up, but here are the contents in case I get the error again:
Code:
limits.h
README
syslimits.h
If you get this, that indicates that fixincludes was screwed up. If you look now you should see a *lot* more files. These are replacement headers that deal with the various errors in the actual headers
Quote:
EDIT 2: To anybody that's thinking of dealing with WPILib, I suggest adding the following flag in CMAKE_CXX_FLAGS to filter out all the deprecated string literal warnings. There's no way that anybody is going to go through the whole library and convert it to using std::string unless that have absolutely no life.
Code:
-Wno-write-strings
Agreed. This is an issue with vxWorks itself. Not much we can do here. If we wanted to we could add a rule to fixincludes, but I don't think a warning that we know to be spurious and can disable is worth the extra effort involved in getting accepted upstream or the complications of building patched source.
Quote:
EDIT 3: Build error was just a fluke. I have no idea what happened. Deleted my build directory, reconfigured and it worked. That was pretty stupid on my part. Sorry for the hassle on that one.
No problem. Sometimes GCC builds fail for random unknown reasons...
Quote:
EDIT 4: The virtual destructor warnings are legit. These are abstract classes with pure abstract methods, and the classes have derived classes. This means that if a derived class were to have an explicit destructor, it wouldn't be getting called. I'll be sure to fix those warnings in the next round of fixes.
And this is why we use compiler warnings!
Quote:
EDIT 5: The master branch on my git repository should fix many of the compiler warnings for wpilib on C++98 as well. I haven't tested compatibility with old versions of GCC yet though. I did leave some unnecessary typedef's in there because I think that they, at some point, were necessary, so WindRiver's version of GCC might still want them and I don't want to break compatibility with it. The C++11 branch has these changes pulled in as well.
Awesome!
  #74   Spotlight this post!  
Unread 17-01-2013, 14:21
CodeYeti's Avatar
CodeYeti CodeYeti is offline
FRC Addict
AKA: Matt Coffin
FRC #0662 (Rocky Mountain Robotics)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2010
Location: Colorado
Posts: 81
CodeYeti is an unknown quantity at this point
Re: Alternate GCC Toolchain

So I'm getting better, but I'm still really stupid with debian packages. I've gotten the binutils installed, so I think I get the process for building these source packages. I downloaded a binutils tarball with wget and then added the debian directory from the git repository to the extracted folder (after renaming the original tarball to fit debian's naming scheme).

Now, I think I should probably install the wrs-headers-installer next, correct? How would I build that package? It's complaining that it can't find an upstream tarball (because I didn't download one). What am I supposed to do with that one? I tried ./debianize, but bash couldn't find dh_make.

Sorry for my noobyness in this area, I really just need to sit down and learn about aptitude a little more when I get the time.

EDIT: Looks like I've found the time, I'm just going through all the wiki pages and everything and doing a few examples with it. Just ignore the post, I'm sure I'll get it after just doing some learning. It's going to be more of a pain in the $@#$@#$@# in the long run to avoid spending the time learning it.

Last edited by CodeYeti : 17-01-2013 at 15:20.
  #75   Spotlight this post!  
Unread 17-01-2013, 15:30
rbmj rbmj is offline
Registered User
FRC #0612 (Chantilly Robotics)
Team Role: Alumni
 
Join Date: Apr 2011
Rookie Year: 2011
Location: DC Area/Fairfax County
Posts: 192
rbmj is a jewel in the roughrbmj is a jewel in the roughrbmj is a jewel in the rough
Re: Alternate GCC Toolchain

I'll upload the other files, which should help with building everything. These include .orig.tar.gz and .debian.tar.gz files IIRC.

The .orig files can be made with the following process with a git archive:

Code:
# in git archive for package $PKG
mkdir ../$PKG-$VERSION
git archive master | tar -x -C ../$PKG-$VERSION
cd ..
tar -cf $PKG_$VERSION.orig.tar $PKG-$VERSION
gzip $PKG_$VERSION.orig.tar
cd $PKG-$VERSION
debuild
Making these packages can be a pain in the rear. The debian/rules makefiles for gcc and wpilib are not code snippets I'm particularly proud of... but they work.

Also, if you make a mistake and the build dies, debian wants to completely rebuild the whole package from a distclean. So don't mess up when you're compiling GCC... you wouldn't believe how much time I wasted only to learn that I forgot to pass -e WIND_BASE to debuild...
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 19:18.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi