Re: [Libusbx-devel] [libusbx] Enable building on all Android architectures, including MIPS. (#133)

[tobygray]

I agree with the architecture change, "all" is a far better choice.

The -llog changes are slightly less straightforward though. The sample and test 
applications for Android don't directly call any Android logging code, so 
shouldn't need to have liblog.so added to their NEEDED sections.

Comparing the linker line from armeabi:
```
Executable : dpfp
~/Android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
 -Wl,--gc-sections -Wl,-z,nocopyreloc 
--sysroot=~/Android/android-ndk-r8e/platforms/android-3/arch-arm 
./obj/local/armeabi/objs/dpfp/__/__/examples/dpfp.o -lgcc 
./obj/local/armeabi/libusb1.0.so -no-canonical-prefixes  -Wl,--no-undefined 
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now   -lc -lm -o 
./obj/local/armeabi/dpfp   
Install: dpfp => libs/armeabi/dpfp
```
to the linker line for mips:
```
Executable : dpfp
~/Android/android-ndk-r8e/toolchains/mipsel-linux-android-4.6/prebuilt/linux-x86_64/bin/mipsel-linux-android-g++
 -Wl,--gc-sections -Wl,-z,nocopyreloc 
--sysroot=~/Android/android-ndk-r8e/platforms/android-9/arch-mips 
./obj/local/mips/objs/dpfp/__/__/examples/dpfp.o -lgcc 
./obj/local/mips/libusb1.0.so -no-canonical-prefixes  -Wl,--no-undefined 
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now   -lc -lm -o ./obj/local/mips/dpfp
~/Android/android-ndk-r8e/toolchains/mipsel-linux-android-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/mipsel-linux-android/4.6/../../../../mipsel-linux-android/bin/ld:
 warning: liblog.so, needed by ./obj/local/mips/libusb1.0.so, not found (try 
using -rpath or -rpath-link)
./obj/local/mips/libusb1.0.so: undefined reference to `__android_log_write'
```

The linker lines for the two appear to have the same options. I suspect that 
this is actually a bug in the mips toolchain in the NDK not invoking the linker 
in the same way as other toolchains.

An alternative would be to tell the linker to be happy to have unresolved 
symbols in shared library dependencies (APP_LDFLAGS := 
-Wl,--allow-shlib-undefined), but that still issues warnings for the MIPS 
builds and would let through other issues.

Instead of adding all the extra LDFLAGS to all the mk files I'd suggest just 
adding APP_LDFLAGS := -llog to Application.mk along the lines of:
```
# Workaround for MIPS toolchain linker being unable to find liblog dependency 
of shared object
# in NDK versions at least up to r9
APP_LDFLAGS := -llog
```

Could you update your pull request to use APP_LDFLAGS? If not then I'm happy to 
generate a new patch which uses it.

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/133#issuecomment-22935387
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [libusbx] Enable building on all Android architectures, including MIPS (working around an MIPS NDK linker bug). (#134)

[tobygray]

The Android build changes look good now, thanks for making those changes.

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/134#issuecomment-23015293
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)

[tobygray]

Hi Manuel,

Regarding the addition of config.h into the testlib.c in b86964a 
, what values were 
you needing to pass? Was it just _WIN32?

Regards,

Toby

On 10/10/13 02:02, Manuel Francisco Naranjo wrote:
>
> Pete,
>
> Don't worry on sounding harsh, I agree with the styling issues, my bad 
> I missed those changes while reviewing what to stage and what not, btw 
> I discovered git add -p, git commit -p and git stash -p thanks to 
> this, very powerful, that's why you are seen those style issues.
>
>   * b8d13f2  :
> don't worry about this one, I will check the style on this commit,
> and also in any other missing, I only worried about windows_usb.{c,h}
>   * 7b4eaa9  : this
> was necessary to keep tracing library cleanup when not creating a
> different context, I agree this shouldn't be part of the branch,
> but it was a feature I needed to figure out where I was leaking
> devices while still writting the code that's why it was still
> there. I think this is a different conversation.
>   * b86964a  : it
> was necessary for mingw building when using my own build tools, as
> I didn't wanted to pass those values through compiler arguments,
> it makes more sense to use the autogenerated config.h
>   * 3de7d1d  :
> declaring those type values was necessary to get mingw building as
> WINVER and /WIN/WINNT aren't defined, but you are right as I'm
> referencing the A version and not the subfixed one I can just rely
> on PTSTR which should be defined.
>   * a3f315d  : I
> can change to bool, about the arguments you mean lines like 981,
> 982 on the resulting code? You prefer code without argument
> comments? If so I can make those one line, otherwise how you want
> me to put the comments?
>   * dfa1d55  and
> c94f9d5  : ok
> makes sense, just wanted to keep track on the changes someone
> suggested for VS2012.
>
> I'll do the suggested fixes and get back to you by the end of the week.
>
> Regards,
> Manuel
>
> —
> Reply to this email directly or view it on GitHub 
> .
>

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/9#issuecomment-26121465--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [libusbx] Windows: hotplug/unplug support (#9)

[tobygray]

@manuelnaranjo shouldn't the #define checks then be changed to OS_WINDOWS and 
OS_WINCE?

Also wouldn't mingw provide a unistd.h which provides the required defines? How 
are you compiling with mingw and what compiler error does it produce without 
including config.h?

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/9#issuecomment-26134617--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel

Re: [Libusbx-devel] [libusbx] Adding support for compiling at *-linux-android platform (#154)

[tobygray]

It would be good to update the android/config.h file for the NDK based builds 
of libusbx for Android so that it doesn't need to have a duplicate definition 
of TIMESPEC_TO_TIMEVAL at the end.

I might have misunderstood the intention, but this change doesn't appear to 
cope with all the possible Android platform names, such as 
"arm-linux-androideabi".

My assumption is that in this change you want to enable support for building 
libusbx for Android using configure? 


---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/154#issuecomment-26796720--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel