I suspect the reason the prior gcc versions work better in some cases is because Makefiles or the build process was written targeting the older OSX libraries, which are used by the older gcc but not the newer one. That’s just a guess though, I never dug deep enough to really understand.

It may be worth trying other gcc versions if you have them, on the off chance one of them will work.

Do you have any insight as to why gcc version 4.0 works, but v4.2 does not?

to install guppy-0.1.9 on Mac OS X 10.6.7. Now I’m off to track down a memory leak ….

public StorageObject[] getObjects(java.lang.String bucketName,
StorageObject[] objects)
throws ServiceException

Also, in future please post JetS3t-related questions to the forum at http://groups.google.com/group/jets3t-users

Questions are difficult to deal with on my blog, the commenting system just isn’t good enough.

Thanks,
James

The code shown above is my test program.

public class WalrusConnector {

public static void main(String[] args) throws S3ServiceException {
String awsAccessKey = “My_AccessKey”;
String awsSecretKey = “My_SecretKey”;
AWSCredentials awsCredentials = new AWSCredentials(awsAccessKey, awsSecretKey);
S3Service s3Service = new RestS3Service(awsCredentials);
org.jets3t.service.Constants.JETS3T_PROPERTIES_FILENAME =”D:\\Java\\ThirdPartyLibs\\jets3t-0.8.0\\configs\\jets3.properties”;
S3Bucket[] myBuckets = s3Service.listAllBuckets();
System.out.println(“How many buckets to I have in S3? ” + myBuckets.length);
}
}

What else should I do to get it work ? By the way, I run the test program in Eclipse 3.5 under windows 7.

Best of luck implementing a Rackspace service for JetS3t, it should be a little easier to do this following the refactoring included with version 0.8.0. However, if you run into trouble don’t forget that there’s also the excellent jClouds library which already includes a Rackspace implementation.

Although JetS3t is no longer specific to the S3 service — with its suport for Google Storage and Amazon CloudFront — I don’t think it’s worthwhile changing the name. JetS3t will remain focused on S3 and services that have a very similar API; I’m not planning for it to become a general-purpose tool for many cloud storage services. There are just too much legacy design and implementation details/issues remaining to make it feasible, and other projects like jClouds are already doing a good job of this.