How would using automake/autoconf help
with cross-compiling? I've never used them, so I don't know. I
was under the impression that they helped if you had a lot of
dependencies, which these libraries don't - only gcc.
I think the problem is that are so many combinations of
processors, EABIs, Linux or other Unix kernel levels, C libraries
and versions (uclibc as well as glibc for example), that deciding
on the targets we wanted to build for would be impossible.
If you are running an OS in the configuration you want, and you
have gcc, it is easy to build - at least for Linux/Unix. If I
want to compile for Pi or whatever, I clone the source with git
and make - job done.
For Windows I prefer the Microsoft compilers, as in my experience
they produce better code. And most developers will also be using
Visual Studio. A Visual Studio project is the obvious solution,
no?
Recently I've been setting up Eclipse Hudson system to build and
test the C clients, for Linux 64-bit (see
https://hudson.eclipse.org/hudson/job/paho-c-dev-nightly/
- the test failures are because we're still setting up the SSL
test environment). I've used Ant, as that seemed to coexist with
Hudson nicely. Proliferating build methods, however, doesn't seem
desirable.
Ian
On 08/22/2013 06:51 PM, Frank Pagliughi wrote:
Are there any thoughts on creating a
more portable build system for the C library? On Linux/Unix, a
traditional automake/autoconf solution that supports
cross-compiling usually makes these problems trivial for
GCC-based cross compilers. I started hacking something together
that I was able to use to compile the library for the specific
BeagleBone and Raspberry Pi versions that I was testing.
But I suppose some other systems might do all this and encompass
Windows and other targets as well?
Frank
On 08/22/2013 09:00 AM, Ian Craggs wrote:
Hi Jan,
I can check those libraries later. But, since I created them
I realized that there are several Linux distributions that are
used on the Raspberry Pi, and this library was built with the
one I installed on my Pi, which is Debian I think.
Those libraries don't necessarily work with other Linux
distributions, or even a different version of the same
distribution. The only sure way will be to build the
libraries yourself, I think.
I think we ought to look to getting the Paho MQTT C client
libraries into the Linux distributions.
Ian
On 08/22/2013 12:37 PM,
jan.bogaerts@xxxxxxxxxx
wrote:
Hi,
I'm trying to use the prebuild paho libraries for the
raspberry-pi, but when I want to run the application, it
can't load the libmqttv3c.so lib. When I check the library
with the ldd command, it says that the files aren't shared
executables, so it can't load them as shared libraries.
Any suggestions?
Cheers,
Jan.
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev
