newbie - can't get include and libs to work

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

newbie - can't get include and libs to work

David Eaton
I'm having trouble just trying to get the basics to work.  I need to use libusb, so I have set up my specs file as attached.  I put quotes around the paths to the include and the lib for libusb as the path contains a space.  When gcc runs, it omits the "c:/program " and says "cc1.exe: files/libusb-win32-0.1.10.1/include": no such file or directory".  Note that the leading quote and c:/program  is missing from the front of the name.  I've tried backslashes as per windows, but that doesn't make any difference.  Everything I need for the include and the lib will be somewhere under "c:\program files", so is there some trick to getting these names recognized?

Thanks in advance!
Dave :)


     
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

gccspecs (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

Keith Marshall
On Thursday 23 October 2008 06:03:07 David Eaton wrote:
> Everything I need for the include and the lib will be somewhere
> under "c:\program files", so is there some trick to getting these
> names recognized?

Yes.  Follow the time honoured instructions, and install your tools
properly.  Spaces in path names are an unnecessary evil; avoid them.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

Soren Andersen
In reply to this post by David Eaton
I'm responding to the message sent on 23 Oct 2008, at around 05:03
UTC, by "David Eaton" <gcos7 ~at~ OBSCURED dot NUL>, who wrote
> I'm having trouble just trying to get the basics to work. I need
> to use libusb, so I have set up my specs file as attached. I put
> quotes around the paths to the include and the lib for libusb as
> the path contains a space. When gcc runs, it omits the
>   «"c:/program»
> and says
>   «cc1.exe: files/libusb-win32-0.1.10.1/include": no such file or
>   directory»

> Note that the leading quote and «c:/program» is missing from the
> front of the name. I've tried backslashes as per windows, but that
> doesn't make any difference. Everything I need for the include and
> the lib will be somewhere under "c:\program files", so is there
> some trick to getting these names recognized?
> Thanks in advance!
> Dave :)

Next reply in this thread (200810230819.24538.[...]), Keith
Marshall wrote:
> Yes.  Follow the time honoured instructions, and install your
> tools properly.  Spaces in path names are an unnecessary evil;
> avoid them.

Keith's answer is the most correct and most beneficial answer you
could possibly receive.  Any other answer will be a work-around
that represents unnecessary complexity (work) instead of going to
the root of the problem. Nevertheless, here's couple ways to deal
with the problem, roughly in increasing order of overkill:

  (1) Use the limited 8.3 ("DOS") transfiguration of the pathnames
   to your devel dirs.  A native CMD.exe approach to finding such
   a pathname would look like

   C:\ >for /D "delims=$" %X in ("C:\Program Files\.") do @ECHO %~fsX

   of course the output will always look like C:\PROGRA~1 unless
   something very very weird has happened on your computer.

  (2) Create a "NTFS directory soft link" (aka 'reparse point' or
   'junction') from an space-free pathname to the space-ish
   pathname(s), e.g.
    C:/libusb-develfiles => «C:/program files/libusb-win32-0.1.10.1»
   using the appropriate tools (Windows2000 or later only, IIRC).
   Such a tool would include SysInternals "junction.exe". See
   Microsoft.com.

Spaces in development directories' pathnames are are very poor
practice (a newbie mistake in fact) because the tools being used
to build binary program files from source code are CLI tools.
The CLI on any computer system is based on a command interpreter
that breaks up arguments to commands on *whitespace*.  This is
true of any *nix sh shell and of CMD.exe. In no way would it be
valid to "expect" that on MS Windows systems, this exingency
is not present. The CMD shell itself and other tools used (like
GNU make) all break up parts of arguments (tokenize) on
whitespace. Furthermore, the CMD.exe shell has far less flexible
escaping (aka "quoting") mechanisms available when compared to a
*nix sh shell; it is logical to suggest that one must be even
more rigorous about one's correct installation practices on the
MS Windows system, then.

 HTH,
  Sören 'somian' Andersen
--
Blame it on Caradhras the Cruel.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

David Eaton
In reply to this post by Keith Marshall
I can only do so much with packages in Windows - when they install themselves in \program files and register themselves, it seems very wasteful of disk space to copy entire packages.  The softlink thing is one I was not aware of and will need to look into.

In the mean time, broken down to it's simplest form:


C:\daves stuff\cvsutil\newsrc\temp>rename a_start.c_cl *.c

C:\daves stuff\cvsutil\newsrc\temp>dir
 Volume in drive C has no label.
 Volume Serial Number is 4668-AD3B

 Directory of C:\daves stuff\cvsutil\newsrc\temp

10/24/2008  02:07 PM    <DIR>          .
10/24/2008  02:07 PM    <DIR>          ..
10/24/2008  12:45 AM             3,067 a_start.c
10/23/2008  02:47 PM             5,839 ops-linux.h
               2 File(s)          8,906 bytes
               2 Dir(s)  146,143,866,880 bytes free

C:\daves stuff\cvsutil\newsrc\temp>gcc *.c -I c:\libusb\include -L c:\libusb\lib
\gcc
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/cccLzHrw.o:a_start.c:(.text+0x4b): undefined
reference to `usb_control_msg'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/cccLzHrw.o:a_start.c:(.text+0xba): undefined
reference to `usb_control_msg'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/cccLzHrw.o:a_start.c:(.text+0x11a): undefined
 reference to `usb_bulk_read'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/cccLzHrw.o:a_start.c:(.text+0x162): undefined
 reference to `usb_bulk_write'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/cccLzHrw.o:a_start.c:(.text+0x1aa): undefined
 reference to `usb_bulk_read'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/cccLzHrw.o:a_start.c:(.text+0x1f2): undefined
 reference to `usb_bulk_write'
/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined reference to `Wi
nMain@16'
collect2: ld returned 1 exit status

C:\daves stuff\cvsutil\newsrc\temp>gcc *.c -I c:\libusb\include\ -L c:\libusb\li
b\gcc\libusb.a
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/ccivjp0l.o:a_start.c:(.text+0x4b): undefined
reference to `usb_control_msg'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/ccivjp0l.o:a_start.c:(.text+0xba): undefined
reference to `usb_control_msg'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/ccivjp0l.o:a_start.c:(.text+0x11a): undefined
 reference to `usb_bulk_read'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/ccivjp0l.o:a_start.c:(.text+0x162): undefined
 reference to `usb_bulk_write'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/ccivjp0l.o:a_start.c:(.text+0x1aa): undefined
 reference to `usb_bulk_read'
C:\DOCUME~1\VALUED~1\LOCALS~1\Temp/ccivjp0l.o:a_start.c:(.text+0x1f2): undefined
 reference to `usb_bulk_write'
/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined reference to `Wi
nMain@16'
collect2: ld returned 1 exit status

C:\daves stuff\cvsutil\newsrc\temp>



The only file in the include path is usb.h, and it's contents follow:
#ifndef __USB_H__
#define __USB_H__

#include <stdlib.h>

/*
 * 'interface' is defined somewhere in the Windows header files. This macro
 * is deleted here to avoid conflicts and compile errors.
 */

#ifdef interface
#undef interface
#endif

/*
 * PATH_MAX from limits.h can't be used on Windows if the dll and
 * import libraries are build/used by different compilers
 */

#define LIBUSB_PATH_MAX 512


/*
 * USB spec information
 *
 * This is all stuff grabbed from various USB specs and is pretty much
 * not subject to change
 */

/*
 * Device and/or Interface Class codes
 */
#define USB_CLASS_PER_INTERFACE 0 /* for DeviceClass */
#define USB_CLASS_AUDIO      1
#define USB_CLASS_COMM      2
#define USB_CLASS_HID        3
#define USB_CLASS_PRINTER      7
#define USB_CLASS_MASS_STORAGE 8
#define USB_CLASS_HUB        9
#define USB_CLASS_DATA      10
#define USB_CLASS_VENDOR_SPEC  0xff

/*
 * Descriptor types
 */
#define USB_DT_DEVICE 0x01
#define USB_DT_CONFIG 0x02
#define USB_DT_STRING 0x03
#define USB_DT_INTERFACE 0x04
#define USB_DT_ENDPOINT 0x05

#define USB_DT_HID 0x21
#define USB_DT_REPORT 0x22
#define USB_DT_PHYSICAL 0x23
#define USB_DT_HUB 0x29

/*
 * Descriptor sizes per descriptor type
 */
#define USB_DT_DEVICE_SIZE 18
#define USB_DT_CONFIG_SIZE 9
#define USB_DT_INTERFACE_SIZE 9
#define USB_DT_ENDPOINT_SIZE 7
#define USB_DT_ENDPOINT_AUDIO_SIZE 9 /* Audio extension */
#define USB_DT_HUB_NONVAR_SIZE 7


/* ensure byte-packed structures */
#include <pshpack1.h>


/* All standard descriptors have these 2 fields in common */
struct usb_descriptor_header {
  unsigned char  bLength;
  unsigned char  bDescriptorType;
};

/* String descriptor */
struct usb_string_descriptor {
  unsigned char  bLength;
  unsigned char  bDescriptorType;
  unsigned short wData[1];
};

/* HID descriptor */
struct usb_hid_descriptor {
  unsigned char  bLength;
  unsigned char  bDescriptorType;
  unsigned short bcdHID;
  unsigned char  bCountryCode;
  unsigned char  bNumDescriptors;
};

/* Endpoint descriptor */
#define USB_MAXENDPOINTS 32
struct usb_endpoint_descriptor {
  unsigned char  bLength;
  unsigned char  bDescriptorType;
  unsigned char  bEndpointAddress;
  unsigned char  bmAttributes;
  unsigned short wMaxPacketSize;
  unsigned char  bInterval;
  unsigned char  bRefresh;
  unsigned char  bSynchAddress;

  unsigned char *extra; /* Extra descriptors */
  int extralen;
};

#define USB_ENDPOINT_ADDRESS_MASK 0x0f    /* in bEndpointAddress */
#define USB_ENDPOINT_DIR_MASK  0x80

#define USB_ENDPOINT_TYPE_MASK 0x03    /* in bmAttributes */
#define USB_ENDPOINT_TYPE_CONTROL    0
#define USB_ENDPOINT_TYPE_ISOCHRONOUS 1
#define USB_ENDPOINT_TYPE_BULK    2
#define USB_ENDPOINT_TYPE_INTERRUPT  3

/* Interface descriptor */
#define USB_MAXINTERFACES 32
struct usb_interface_descriptor {
  unsigned char  bLength;
  unsigned char  bDescriptorType;
  unsigned char  bInterfaceNumber;
  unsigned char  bAlternateSetting;
  unsigned char  bNumEndpoints;
  unsigned char  bInterfaceClass;
  unsigned char  bInterfaceSubClass;
  unsigned char  bInterfaceProtocol;
  unsigned char  iInterface;

  struct usb_endpoint_descriptor *endpoint;

  unsigned char *extra; /* Extra descriptors */
  int extralen;
};

#define USB_MAXALTSETTING 128 /* Hard limit */

struct usb_interface {
  struct usb_interface_descriptor *altsetting;

  int num_altsetting;
};

/* Configuration descriptor information.. */
#define USB_MAXCONFIG 8
struct usb_config_descriptor {
  unsigned char  bLength;
  unsigned char  bDescriptorType;
  unsigned short wTotalLength;
  unsigned char  bNumInterfaces;
  unsigned char  bConfigurationValue;
  unsigned char  iConfiguration;
  unsigned char  bmAttributes;
  unsigned char  MaxPower;

  struct usb_interface *interface;

  unsigned char *extra; /* Extra descriptors */
  int extralen;
};

/* Device descriptor */
struct usb_device_descriptor {
  unsigned char  bLength;
  unsigned char  bDescriptorType;
  unsigned short bcdUSB;
  unsigned char  bDeviceClass;
  unsigned char  bDeviceSubClass;
  unsigned char  bDeviceProtocol;
  unsigned char  bMaxPacketSize0;
  unsigned short idVendor;
  unsigned short idProduct;
  unsigned short bcdDevice;
  unsigned char  iManufacturer;
  unsigned char  iProduct;
  unsigned char  iSerialNumber;
  unsigned char  bNumConfigurations;
};

struct usb_ctrl_setup {
  unsigned char  bRequestType;
  unsigned char  bRequest;
  unsigned short wValue;
  unsigned short wIndex;
  unsigned short wLength;
};

/*
 * Standard requests
 */
#define USB_REQ_GET_STATUS    0x00
#define USB_REQ_CLEAR_FEATURE    0x01
/* 0x02 is reserved */
#define USB_REQ_SET_FEATURE    0x03
/* 0x04 is reserved */
#define USB_REQ_SET_ADDRESS    0x05
#define USB_REQ_GET_DESCRIPTOR 0x06
#define USB_REQ_SET_DESCRIPTOR 0x07
#define USB_REQ_GET_CONFIGURATION 0x08
#define USB_REQ_SET_CONFIGURATION 0x09
#define USB_REQ_GET_INTERFACE  0x0A
#define USB_REQ_SET_INTERFACE  0x0B
#define USB_REQ_SYNCH_FRAME    0x0C

#define USB_TYPE_STANDARD (0x00 << 5)
#define USB_TYPE_CLASS (0x01 << 5)
#define USB_TYPE_VENDOR (0x02 << 5)
#define USB_TYPE_RESERVED (0x03 << 5)

#define USB_RECIP_DEVICE 0x00
#define USB_RECIP_INTERFACE 0x01
#define USB_RECIP_ENDPOINT 0x02
#define USB_RECIP_OTHER 0x03

/*
 * Various libusb API related stuff
 */

#define USB_ENDPOINT_IN 0x80
#define USB_ENDPOINT_OUT 0x00

/* Error codes */
#define USB_ERROR_BEGIN 500000

/*
 * This is supposed to look weird. This file is generated from autoconf
 * and I didn't want to make this too complicated.
 */
#define USB_LE16_TO_CPU(x)

/* Data types */
/* struct usb_device; */
/* struct usb_bus; */

struct usb_device {
  struct usb_device *next, *prev;

  char filename[LIBUSB_PATH_MAX];

  struct usb_bus *bus;

  struct usb_device_descriptor descriptor;
  struct usb_config_descriptor *config;

  void *dev; /* Darwin support */

  unsigned char devnum;

  unsigned char num_children;
  struct usb_device **children;
};

struct usb_bus {
  struct usb_bus *next, *prev;

  char dirname[LIBUSB_PATH_MAX];

  struct usb_device *devices;
  unsigned long location;

  struct usb_device *root_dev;
};

/* Version information, Windows specific */
struct usb_version {
  struct {
    int major;
    int minor;
    int micro;
    int nano;
  } dll;
  struct {
    int major;
    int minor;
    int micro;
    int nano;
  } driver;
};


struct usb_dev_handle;
typedef struct usb_dev_handle usb_dev_handle;

/* Variables */
extern struct usb_bus *usb_busses;


#include <poppack.h>


#ifdef __cplusplus
extern "C" {
#endif

  /* Function prototypes */

  /* usb.c */
  usb_dev_handle *usb_open(struct usb_device *dev);
  int usb_close(usb_dev_handle *dev);
  int usb_get_string(usb_dev_handle *dev, int index, int langid, char *buf,
                     size_t buflen);
  int usb_get_string_simple(usb_dev_handle *dev, int index, char *buf,
                            size_t buflen);

  /* descriptors.c */
  int usb_get_descriptor_by_endpoint(usb_dev_handle *udev, int ep,
                                     unsigned char type, unsigned char index,
                                     void *buf, int size);
  int usb_get_descriptor(usb_dev_handle *udev, unsigned char type,
                         unsigned char index, void *buf, int size);

  /* <arch>.c */
  int usb_bulk_write(usb_dev_handle *dev, int ep, char *bytes, int size,
                     int timeout);
  int usb_bulk_read(usb_dev_handle *dev, int ep, char *bytes, int size,
                    int timeout);
  int usb_interrupt_write(usb_dev_handle *dev, int ep, char *bytes, int size,
                          int timeout);
  int usb_interrupt_read(usb_dev_handle *dev, int ep, char *bytes, int size,
                         int timeout);
  int usb_control_msg(usb_dev_handle *dev, int requesttype, int request,
                      int value, int index, char *bytes, int size,
                      int timeout);
  int usb_set_configuration(usb_dev_handle *dev, int configuration);
  int usb_claim_interface(usb_dev_handle *dev, int interface);
  int usb_release_interface(usb_dev_handle *dev, int interface);
  int usb_set_altinterface(usb_dev_handle *dev, int alternate);
  int usb_resetep(usb_dev_handle *dev, unsigned int ep);
  int usb_clear_halt(usb_dev_handle *dev, unsigned int ep);
  int usb_reset(usb_dev_handle *dev);

  char *usb_strerror(void);

  void usb_init(void);
  void usb_set_debug(int level);
  int usb_find_busses(void);
  int usb_find_devices(void);
  struct usb_device *usb_device(usb_dev_handle *dev);
  struct usb_bus *usb_get_busses(void);


  /* Windows specific functions */

  #define LIBUSB_HAS_INSTALL_SERVICE_NP 1
  int usb_install_service_np(void);

  #define LIBUSB_HAS_UNINSTALL_SERVICE_NP 1
  int usb_uninstall_service_np(void);

  #define LIBUSB_HAS_INSTALL_DRIVER_NP 1
  int usb_install_driver_np(const char *inf_file);
 
  const struct usb_version *usb_get_version(void);

  int usb_isochronous_setup_async(usb_dev_handle *dev, void **context,
                                  unsigned char ep, int pktsize);
  int usb_bulk_setup_async(usb_dev_handle *dev, void **context,
                           unsigned char ep);
  int usb_interrupt_setup_async(usb_dev_handle *dev, void **context,
                                unsigned char ep);

  int usb_submit_async(void *context, char *bytes, int size);
  int usb_reap_async(void *context, int timeout);
  int usb_free_async(void **context);


#ifdef __cplusplus
}
#endif

#endif /* __USB_H__ */



The program, a_start.c, contains the following:

#include "ops-linux.h"

#if defined(_WIN32)
#include <usb.h>
#endif



It also has the following libusb calls:

/**************************************************************
  This set of routines do the lower-level calls for reading
  and writing to USB devices.

  All similar routines are included here, so this file
  applies to both the camcorder and the still camera.
***************************************************************/


int ControlMessageRead(u16 command, char *data, int size, int timeout)
{

        int x = usb_control_msg(m_p_handle,
                          USB_ENDPOINT_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
                          0x01,
                          command,
                          0x0000,
                          data,
                          size,
                          timeout );

        if(x < size)
                return FALSE;

        return TRUE;
}



int ControlMessageWrite(u16 command, char * data, int size, int timeout)
{

        int x=usb_control_msg(m_p_handle,
                        USB_ENDPOINT_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
                        0x01,
                        command,
                        0x0101,
                        data,
                        size,
                        timeout);
        /*  data can't be made const since usb_control_msg won't handle const char */

        if(x < size)
                return FALSE;
        return TRUE;
}



int Read(char *p_buffer, unsigned int length, int timeout)
{

        int bytes_read = -1;
 
        if (m_p_handle)
                bytes_read = usb_bulk_read(m_p_handle,READ_ENDPOINT,p_buffer,length,timeout);

        return bytes_read;
}




int Write(char * p_buffer, unsigned int length, int timeout)
{

        int bytes_written = -1;

        if (m_p_handle)
                bytes_written = usb_bulk_write(m_p_handle,WRITE_ENDPOINT,p_buffer,length,timeout);

        return bytes_written;
}




int camera_Read( char* p_buffer, unsigned int length, int timeout /* = TIMEOUT */)
{

        int bytes_read = -1;
        if (m_p_handle)
        {
                bytes_read = usb_bulk_read(m_p_handle,CAMERA_READ_ENDPOINT,p_buffer,length,timeout);
        }

        return bytes_read;
}




int camera_Write(char* p_buffer, unsigned int length, int timeout /* = TIMEOUT */)
{

        int bytes_written = -1;

        if (m_p_handle)
        {
                bytes_written = usb_bulk_write(m_p_handle,CAMERA_WRITE_ENDPOINT,p_buffer,length,timeout);

        }

        return bytes_written;
}



Note that it is not finding the references to the libusb routines defined in the usb.h header file.

Now, I hope that is enough for someone to give me some direction.  I appreciate the general comments, and I understand about not liking spaces in a path - but in windows, given everything installing in \Program File, it is a given the path will have imbedded spaces.  Any attempts at quoting these has failed.  So I copied everything to another folder, a big waste of disk space, to perform this test.

Thanks in advance,
Dave :)




     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

Роман Донченко
In reply to this post by Soren Andersen
> Spaces in development directories' pathnames are are very poor
> practice (a newbie mistake in fact) because the tools being used
> to build binary program files from source code are CLI tools.
> The CLI on any computer system is based on a command interpreter
> that breaks up arguments to commands on *whitespace*.  This is
> true of any *nix sh shell and of CMD.exe.

Uh, no. First of all, Windows command interpreter doesn't break up arguments
at all. It only needs to tell the filename apart from the arguments. Second,
this can actually be done without any spaces (e.g. DIR/ON/B).
Of course, it still parses the command line to do I/O redirection, shell
variable expansion and other crazy stuff.

> In no way would it be
> valid to "expect" that on MS Windows systems, this exingency
> is not present. The CMD shell itself and other tools used (like
> GNU make) all break up parts of arguments (tokenize) on
> whitespace. Furthermore, the CMD.exe shell has far less flexible
> escaping (aka "quoting") mechanisms available when compared to a
> *nix sh shell; it is logical to suggest that one must be even
> more rigorous about one's correct installation practices on the
> MS Windows system, then.

According to the above, replace "CMD.exe shell escaping mechanisms" with
"common algorithm for command line parsing as perpetrated by the Microsoft C
runtime and CommandLineToArgvW". Even then, the escaping mechanism, though
idiosyncratic, is adequate for the task:

" spaces spaces everywhere "
" one quotation mark: \" "
" a backslash: \ "
" a backslash and a quote: \\\" "

And quotes can't appear in filenames, anyway.

The point I was trying to make is that it is NOT unreasonable to expect your
tools to handle your files. Spaces have been being allowed in filenames
since who knows when, and ignoring them is just laziness on the part of
developers.

Roman.

--
Manually typed signature.



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

Роман Донченко
In reply to this post by David Eaton
> C:\daves stuff\cvsutil\newsrc\temp>gcc *.c -I c:\libusb\include -L
> c:\libusb\lib

You still need to tell GCC to link with the library. Given that the library
is libusb.a, I suggest appending -lusb to the above.

Roman.



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

Keith Marshall
In reply to this post by Роман Донченко
On Friday 24 October 2008 20:22:06 Роман Донченко wrote:
> Spaces have been being allowed in filenames
> since who knows when, and ignoring them is just laziness on the
> part of developers.

Just because they are allowed, doesn't mean you must use them.  FWIW,
my (human) brain finds them objectionable, and difficult to parse.

If avoiding unnecessary work is laziness, then ok, I am lazy.  Spaces
in path names are an easily avoided obstacle to productivity.  I have
better things to do with my time, than to waste it on problems which
are completely avoidable.

Since every Windows program is left to it's own devices, when it comes
to parsing command lines, there is no guarantee that two programs
will even interpret a common argument vector in the same fashion.  
Add to that the probability that, particularly within makefiles, the
same quoting construct may appear in multiple contexts, with some
requiring more than one trip through a parser, and where each round
trip removes a level of quoting; you end up with overquoting in one
context, underquoting in another.

This is potentially a very difficult problem to solve robustly; if
indeed it is possible at all, it could take several lifetimes.  Life
is too short; for your sanity, I advise you to avoid spaces in path
names.  Ignore that advice, if you wish; don't expect sympathy when
you get bitten.

Regards,
Keith.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

David Eaton
All of this talk of no spaces sounds great as words - but again, look at the platform -> Windows.  Windows not only allows it (which says that tools that run in Windows should adhere to what it allows) but PROMOTES it by having everything install to "\Program Files".  As much as it is nice to talk about "just moving things", this in REAL life with Windows is not practical.

Now, enough on that subject, what about helping me with my problem?  I posted a long detailed email as it seems many wanted.  I'm still waiting on a reply on that rather than wasting time argueing about a defacto standard in Windows.  Don't like spaces in a path? Try another OS.

Dave :)


--- On Fri, 10/24/08, Keith Marshall <[hidden email]> wrote:

> From: Keith Marshall <[hidden email]>
> Subject: Re: [Mingw-users] newbie - can't get include and libs to work
> To: [hidden email]
> Date: Friday, October 24, 2008, 5:42 PM
> On Friday 24 October 2008 20:22:06 Роман
> Донченко wrote:
> > Spaces have been being allowed in filenames
> > since who knows when, and ignoring them is just
> laziness on the
> > part of developers.
>
> Just because they are allowed, doesn't mean you must
> use them.  FWIW,
> my (human) brain finds them objectionable, and difficult to
> parse.
>
> If avoiding unnecessary work is laziness, then ok, I am
> lazy.  Spaces
> in path names are an easily avoided obstacle to
> productivity.  I have
> better things to do with my time, than to waste it on
> problems which
> are completely avoidable.
>
> Since every Windows program is left to it's own
> devices, when it comes
> to parsing command lines, there is no guarantee that two
> programs
> will even interpret a common argument vector in the same
> fashion.  
> Add to that the probability that, particularly within
> makefiles, the
> same quoting construct may appear in multiple contexts,
> with some
> requiring more than one trip through a parser, and where
> each round
> trip removes a level of quoting; you end up with
> overquoting in one
> context, underquoting in another.
>
> This is potentially a very difficult problem to solve
> robustly; if
> indeed it is possible at all, it could take several
> lifetimes.  Life
> is too short; for your sanity, I advise you to avoid spaces
> in path
> names.  Ignore that advice, if you wish; don't expect
> sympathy when
> you get bitten.
>
> Regards,
> Keith.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe
> at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

David Eaton
In reply to this post by Роман Донченко
THANKS!!!  I will try that asap.  It was nice to get a response and not more agruement on whitespace in a path.  Thank you!!

Dave :)


--- On Fri, 10/24/08, Роман Донченко <[hidden email]> wrote:

> From: Роман Донченко <[hidden email]>
> Subject: Re: [Mingw-users] newbie - can't get include and libs to work
> To: [hidden email]
> Date: Friday, October 24, 2008, 2:27 PM
> > C:\daves
> stuff\cvsutil\newsrc\temp>gcc *.c -I
> c:\libusb\include -L
> > c:\libusb\lib
>
> You still need to tell GCC to link with the library. Given
> that the library
> is libusb.a, I suggest appending -lusb to the above.
>
> Roman.
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe
> at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

John Clizbe
In reply to this post by David Eaton
David Eaton wrote:

> All of this talk of no spaces sounds great as words - but again, look at the
> platform -> Windows. Windows not only allows it (which says that tools that run
> in Windows should adhere to what it allows) but PROMOTES it by having everything
> install to "\Program Files". As much as it is nice to talk about "just moving
> things", this in REAL life with Windows is not practical.
>
> Now, enough on that subject, what about helping me with my problem? I posted
> a long detailed email as it seems many wanted. I'm still waiting on a reply on
> that rather than wasting time arguing about a de facto standard in Windows.
> Don't like spaces in a path? Try another OS.

Have you tried using 8.3 style names?

\Documents and Settings\ ==> \DOCUME~1\
\Program Files\ ==> \PROGRA~1\

DIR/X at a cmd prompt should help

It's also helpful to remove spaces from %PATH%.

FWIW, all the MinGW docs say not to install to a path with breaking characters
in the name. It's C:\MinGW\ and C:\MSYS by default. Doing otherwise leads to
breakage.

Also, Please don't top post.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

David Eaton
In reply to this post by Роман Донченко
Thanks, Roman.  I'm still getting the errors, and usb.h is not being found.  I tried both "<>" and just quotes around the include for usb.h, but with no difference.  The only thing in c:\libusb\include is usb.h, so it would appear it still is not picking up the include path.



C:\daves stuff\cvsutil\newsrc\temp>gcc *.c -o dwetest -I c:\libsub\include\ -lus
b -L c:\libusb\lib\gcc -lusb
In file included from a_start.c:13:
ops-linux.h:6:17: usb.h: No such file or directory
a_start.c: In function `ControlMessageRead':
a_start.c:61: error: `USB_ENDPOINT_IN' undeclared (first use in this function)
a_start.c:61: error: (Each undeclared identifier is reported only once
a_start.c:61: error: for each function it appears in.)
a_start.c:61: error: `USB_TYPE_VENDOR' undeclared (first use in this function)
a_start.c:61: error: `USB_RECIP_DEVICE' undeclared (first use in this function)
a_start.c: In function `ControlMessageWrite':
a_start.c:81: error: `USB_ENDPOINT_OUT' undeclared (first use in this function)
a_start.c:81: error: `USB_TYPE_VENDOR' undeclared (first use in this function)
a_start.c:81: error: `USB_RECIP_DEVICE' undeclared (first use in this function)

C:\daves stuff\cvsutil\newsrc\temp>


The other thing worth noting at least to me as that according to the "help", gcc doesn't support -I or -L at the command line, even though it did seem to take it when in a specs file:


C:\daves stuff\cvsutil\newsrc\temp>gcc --help
Usage: gcc [options] file...
Options:
  -pass-exit-codes         Exit with highest error code from a phase
  --help                   Display this information
  --target-help            Display target specific command line options
  (Use '-v --help' to display command line options of sub-processes)
  -dumpspecs               Display all of the built in spec strings
  -dumpversion             Display the version of the compiler
  -dumpmachine             Display the compiler's target processor
  -print-search-dirs       Display the directories in the compiler's search path

  -print-libgcc-file-name  Display the name of the compiler's companion library
  -print-file-name=<lib>   Display the full path to library <lib>
  -print-prog-name=<prog>  Display the full path to compiler component <prog>
  -print-multi-directory   Display the root directory for versions of libgcc
  -print-multi-lib         Display the mapping between command line options and
                           multiple library search directories
  -print-multi-os-directory Display the relative path to OS libraries
  -Wa,<options>            Pass comma-separated <options> on to the assembler
  -Wp,<options>            Pass comma-separated <options> on to the preprocessor

  -Wl,<options>            Pass comma-separated <options> on to the linker
  -Xassembler <arg>        Pass <arg> on to the assembler
  -Xpreprocessor <arg>     Pass <arg> on to the preprocessor
  -Xlinker <arg>           Pass <arg> on to the linker
  -save-temps              Do not delete intermediate files
  -pipe                    Use pipes rather than intermediate files
  -time                    Time the execution of each subprocess
  -specs=<file>            Override built-in specs with the contents of <file>
  -std=<standard>          Assume that the input sources are for <standard>
  -B <directory>           Add <directory> to the compiler's search paths
  -b <machine>             Run gcc for target <machine>, if installed
  -V <version>             Run gcc version number <version>, if installed
  -v                       Display the programs invoked by the compiler
  -###                     Like -v but options quoted and commands not executed
  -E                       Preprocess only; do not compile, assemble or link
  -S                       Compile only; do not assemble or link
  -c                       Compile and assemble, but do not link
  -o <file>                Place the output into <file>
  -x <language>            Specify the language of the following input files
                           Permissible languages include: c c++ assembler none
                           'none' means revert to the default behavior of
                           guessing the language based on the file's extension

Options starting with -g, -f, -m, -O, -W, or --param are automatically
 passed on to the various sub-processes invoked by gcc.  In order to pass
 other options on to these processes the -W<letter> options must be used.

For bug reporting instructions, please see:
<URL:http://www.mingw.org/bugs.shtml>.

C:\daves stuff\cvsutil\newsrc\temp>


I then tried the -B since it seems to be the only thing suggesting an include path:

C:\daves stuff\cvsutil\newsrc\temp>gcc *.c -o dwetest -B c:\libsub\include\ -lus
b -L c:\libusb\lib\gcc -lusb
In file included from a_start.c:13:
ops-linux.h:6:17: usb.h: No such file or directory
a_start.c: In function `ControlMessageRead':
a_start.c:61: error: `USB_ENDPOINT_IN' undeclared (first use in this function)
a_start.c:61: error: (Each undeclared identifier is reported only once
a_start.c:61: error: for each function it appears in.)
a_start.c:61: error: `USB_TYPE_VENDOR' undeclared (first use in this function)
a_start.c:61: error: `USB_RECIP_DEVICE' undeclared (first use in this function)
a_start.c: In function `ControlMessageWrite':
a_start.c:81: error: `USB_ENDPOINT_OUT' undeclared (first use in this function)
a_start.c:81: error: `USB_TYPE_VENDOR' undeclared (first use in this function)
a_start.c:81: error: `USB_RECIP_DEVICE' undeclared (first use in this function)

C:\daves stuff\cvsutil\newsrc\temp>



Next, just to test, I took off the -L and -lusb stuff:

C:\daves stuff\cvsutil\newsrc\temp>gcc *.c -o dwetest -B c:\libsub\include\
In file included from a_start.c:13:
ops-linux.h:6:17: usb.h: No such file or directory
a_start.c: In function `ControlMessageRead':
a_start.c:61: error: `USB_ENDPOINT_IN' undeclared (first use in this function)
a_start.c:61: error: (Each undeclared identifier is reported only once
a_start.c:61: error: for each function it appears in.)
a_start.c:61: error: `USB_TYPE_VENDOR' undeclared (first use in this function)
a_start.c:61: error: `USB_RECIP_DEVICE' undeclared (first use in this function)
a_start.c: In function `ControlMessageWrite':
a_start.c:81: error: `USB_ENDPOINT_OUT' undeclared (first use in this function)
a_start.c:81: error: `USB_TYPE_VENDOR' undeclared (first use in this function)
a_start.c:81: error: `USB_RECIP_DEVICE' undeclared (first use in this function)

C:\daves stuff\cvsutil\newsrc\temp>


Then as 1 last test without the trailing slash to the include path:

C:\daves stuff\cvsutil\newsrc\temp>gcc *.c -o dwetest -B c:\libsub\include
In file included from a_start.c:13:
ops-linux.h:6:17: usb.h: No such file or directory
a_start.c: In function `ControlMessageRead':
a_start.c:61: error: `USB_ENDPOINT_IN' undeclared (first use in this function)
a_start.c:61: error: (Each undeclared identifier is reported only once
a_start.c:61: error: for each function it appears in.)
a_start.c:61: error: `USB_TYPE_VENDOR' undeclared (first use in this function)
a_start.c:61: error: `USB_RECIP_DEVICE' undeclared (first use in this function)
a_start.c: In function `ControlMessageWrite':
a_start.c:81: error: `USB_ENDPOINT_OUT' undeclared (first use in this function)
a_start.c:81: error: `USB_TYPE_VENDOR' undeclared (first use in this function)
a_start.c:81: error: `USB_RECIP_DEVICE' undeclared (first use in this function)

C:\daves stuff\cvsutil\newsrc\temp>


It just appears to me that no matter what I do, it is not finding the include path and therefore is not finding usb.h.

I easily confess that I am lost.

Dave :(




     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

David Eaton
In reply to this post by John Clizbe
I'll try the 8.3 syntax and see if I have any luck, however I believe that c:\libusb\include already meets that.

I'm sorry, but I don't know what top post is, so if someone would be so kind to inform me I'll be sure not to do it again.  In the mean time, I apologize if my ignorance in using the mail list has caused problems for anyone!

Dave :)


--- On Fri, 10/24/08, John Clizbe <[hidden email]> wrote:

> From: John Clizbe <[hidden email]>
> Subject: Re: [Mingw-users] newbie - can't get include and libs to work
> To: "MinGW Users List" <[hidden email]>
> Date: Friday, October 24, 2008, 9:12 PM
> David Eaton wrote:
> > All of this talk of no spaces sounds great as words -
> but again, look at the
> > platform -> Windows. Windows not only allows it
> (which says that tools that run
> > in Windows should adhere to what it allows) but
> PROMOTES it by having everything
> > install to "\Program Files". As much as
> it is nice to talk about "just moving
> > things", this in REAL life with Windows is not
> practical.
> >
> > Now, enough on that subject, what about helping me
> with my problem? I posted
> > a long detailed email as it seems many wanted. I'm
> still waiting on a reply on
> > that rather than wasting time arguing about a de facto
> standard in Windows.
> > Don't like spaces in a path? Try another OS.
>
> Have you tried using 8.3 style names?
>
> \Documents and Settings\ ==> \DOCUME~1\
> \Program Files\ ==> \PROGRA~1\
>
> DIR/X at a cmd prompt should help
>
> It's also helpful to remove spaces from %PATH%.
>
> FWIW, all the MinGW docs say not to install to a path with
> breaking characters
> in the name. It's C:\MinGW\ and C:\MSYS by
> default. Doing otherwise leads to
> breakage.
>
> Also, Please don't top post.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe
> at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

Soren Andersen
In reply to this post by Роман Донченко
Quoting Роман Донченко <DXDragon ~at~ [OBSCURED].ru>:

[Soren Andersen:]

> > Spaces in development directories' pathnames are are very poor
> > practice (a newbie mistake in fact) because the tools being used
> > to build binary program files from source code are CLI tools.
> > The CLI on any computer system is based on a command interpreter
> > that breaks up arguments to commands on *whitespace*.  This is
> > true of any *nix sh shell and of CMD.exe.
>
> Uh, no. First of all, Windows command interpreter doesn't break up
> arguments
> at all.
I'm sorry that you are wrong and that you made such an error so publicly. The rest of what you wrote to support your unwise over-confidence pertains to specific subcommands internal to the CMD.exe interpreter:

> It only needs to tell the filename apart from the
> arguments. Second,
> this can actually be done without any spaces (e.g. DIR/ON/B).
> Of course, it still parses the command line to do I/O redirection,
> shell
> variable expansion and other crazy stuff.
> Roman.

I'm sorry for you that you cannot tell an entire elephant from an elephant's trunk. It might help to step back a few paces, and maybe check with your local optician ;-/.

   Regards,
     Soren 'somian' Andersen


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

Brian Dessent
In reply to this post by David Eaton
David Eaton wrote:

> It just appears to me that no matter what I do, it is not finding the include path and therefore is not finding usb.h.

There should not be a space after -I or -L.  There's a typo in that you
spelled libusb as libsub.  In general you should always use forward
slash.  You only need to specify -lusb once:

gcc *.c -o dwetest -Ic:/libusb/include/ -Lc:/libusb/lib/gcc -lusb

Brian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

David Eaton
Thanks, Brian - that seems to have helped.....but...now I get another error I don't understand (main.c doesn't appear anywhere in a_start.c as shown - it follows after the execution copy):


C:\daves stuff\cvsutil\newsrc\temp>gcc *.c -o dwetest -Ic:/libusb/include -L
ibusb/lib/gcc -lusb
/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined reference to
nMain@16'
collect2: ld returned 1 exit status

C:\daves stuff\cvsutil\newsrc\temp>dir



/********************************************************
         a_start.c_cl

  This is used as the first c process encountered in
  the compilation so as to declare extra globals, etc.

  This is used when being run from the command line.
  Usage:  Copy this file to a_start.c before compiling.
*********************************************************/



#include "ops-linux.h"

#include "usb.h"

#define N_KEYS 0
#define SATURNKEYSFILENAME "/.saturnkeys"
#define TRUE 1
#define FALSE 0

    char key_filename[100];

    unsigned char challenge[141];

    int n_keys = N_KEYS;

    char keydesc[255][128] = {};
    unsigned char key[255][2][128] = {};


    int CAM_OPEN = FALSE;
    int CAM_UNLOCKED = FALSE;
    int CAM_TYPE = 0; /* 1 = camcorder, 2 = camera  */
    int CLOSED_CAM_TYPE = 0;
    int DOING_INIT = 0;
    int DONTLOG = 0;
    int RUN_TYPE = 1;   /*  1 for command line, 2 for windowed   */
    int linenum = 0;
    int charcount=0;







/**************************************************************
  This set of routines do the lower-level calls for reading
  and writing to USB devices.

  All similar routines are included here, so this file
  applies to both the camcorder and the still camera.
***************************************************************/


int ControlMessageRead(u16 command, char *data, int size, int timeout)
{

        int x = usb_control_msg(m_p_handle,
                          USB_ENDPOINT_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
                          0x01,
                          command,
                          0x0000,
                          data,
                          size,
                          timeout );

        if(x < size)
                return FALSE;

        return TRUE;
}



int ControlMessageWrite(u16 command, char * data, int size, int timeout)
{

        int x=usb_control_msg(m_p_handle,
                        USB_ENDPOINT_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
                        0x01,
                        command,
                        0x0101,
                        data,
                        size,
                        timeout);
        /*  data can't be made const since usb_control_msg won't handle const char */

        if(x < size)
                return FALSE;
        return TRUE;
}



int Read(char *p_buffer, unsigned int length, int timeout)
{

        int bytes_read = -1;
 
        if (m_p_handle)
                bytes_read = usb_bulk_read(m_p_handle,READ_ENDPOINT,p_buffer,length,timeout);

        return bytes_read;
}




int Write(char * p_buffer, unsigned int length, int timeout)
{

        int bytes_written = -1;

        if (m_p_handle)
                bytes_written = usb_bulk_write(m_p_handle,WRITE_ENDPOINT,p_buffer,length,timeout);

        return bytes_written;
}




int camera_Read( char* p_buffer, unsigned int length, int timeout /* = TIMEOUT */)
{

        int bytes_read = -1;
        if (m_p_handle)
        {
                bytes_read = usb_bulk_read(m_p_handle,CAMERA_READ_ENDPOINT,p_buffer,length,timeout);
        }

        return bytes_read;
}




int camera_Write(char* p_buffer, unsigned int length, int timeout /* = TIMEOUT */)
{

        int bytes_written = -1;

        if (m_p_handle)
        {
                bytes_written = usb_bulk_write(m_p_handle,CAMERA_WRITE_ENDPOINT,p_buffer,length,timeout);

        }

        return bytes_written;
}


Obviously there is no main there - main occurs in a large .c file and to try to compile it requires compiling everything, and everyone has indicated I need to get this to work on a single file first.

Thanks!
Dave :)




--- On Fri, 10/24/08, Brian Dessent <[hidden email]> wrote:

> From: Brian Dessent <[hidden email]>
> Subject: Re: [Mingw-users] newbie - can't get include and libs to work
> To: "MinGW Users List" <[hidden email]>
> Date: Friday, October 24, 2008, 9:28 PM
> David Eaton wrote:
>
> > It just appears to me that no matter what I do, it is
> not finding the include path and therefore is not finding
> usb.h.
>
> There should not be a space after -I or -L.  There's a
> typo in that you
> spelled libusb as libsub.  In general you should always use
> forward
> slash.  You only need to specify -lusb once:
>
> gcc *.c -o dwetest -Ic:/libusb/include/ -Lc:/libusb/lib/gcc
> -lusb
>
> Brian
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe
> at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

Soren Andersen
In reply to this post by David Eaton
Quoting David Eaton <gcos7 ~at~ OBSCURED dot NUL>:
> All of this talk of no spaces sounds great as words - but again,
> look at the platform -> Windows.  Windows not only allows it (which
> says that tools that run in Windows should adhere to what it
> allows) but PROMOTES it by having everything install to "\Program Files".

Is _that_ what you can cite as supporting "proof" that your contention is correct? That's a shame. Clearly you haven't been near the *next* OS release after Windows XP yet, or you'd know better than to try to dismiss the discussion based on such a shakey, miniscule piece of "proof".

The embedded spaces problem is so large and was such a mistake on M$'s part that on Vista, Microsoft's default, out-of-the-box configuration has soft links that alias *space-free path names* to the old spacey ones (left there for, of course, backwards compatibility).  Such a pain in the kiester problem that _even_ Microsoft, that towering edifice of clueless out-of-touchness, got the message.

>  As much as it is nice to talk about "just moving things",
> this in REAL life with Windows is not practical.

Getting a little bit personal for a moment, what I found after several years of being a major ass on the technical fora online, was that no one wanted to communicate with me anymore. I tended to feel things like "these blowhard know-it-alls need to be taken down a peg or two" and "I won't let them get to me, I know I am right and I am going to win this argument." Sound familiar? That's the kind of ego-illness that we saw earlier this week from Tim S. and now you are doing a great job of demonstrating it too. THIS is an example of a strategy that simply doesn't serve one well in *REAL life*. Talk to someone about this with a determined mind to deal with *practicalities* and you'll find that you need to work on something more fundamental than libusb, Dave.

You might want to remember that you apparently came to MinGW-Users in order to locate and communicate with *some folks who might know a bit more than you do*. Apparently you are extremely selective about what you'll hear though. So...

> Now, enough on that subject, what about helping me with my problem?
Due to the truly mind-boggling, overweening, "I have to be right and damn other people" arrogance you are displaying, I've completely lost interest in helping you with anything else, now or in the future.

> Dave :)

Drifting back to the non-personal, I'll note that C (the programming technology) has an automatic notion of argv -- that's an array into which the arguments to a program are placed. One can easily determine for one's self how CMD parses commandlines by writing a simple test program to display all elements present in argv.

   Soren 'somian' Andersen :-)


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

David Eaton
In reply to this post by Soren Andersen
Hey guys!!  Thanks to the pointer on not having a space between the "-I" and the include path and the "-L" and the library path, things have gotten WAY further.  I updated the specs file to include these.  Now it's getting an error trying to find libusb as I specified.  So, I think with all of your help I'm getting real close!  Here's the screen output now:

C:\daves stuff\cvsutil\newsrc\temp>gcc -o dwetest -Ic:/libusb/include/ -Lc:/libu
sb/lib/gcc/ -llibusb.a a_start.c
c:\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot fin
d -llibusb.a
collect2: ld returned 1 exit status

C:\daves stuff\cvsutil\newsrc\temp>


I tried this as just -lusb and got more of the usb functions not defined again.  With just -llibusb I get the same error as posted above.

Thank you so much for the help!!  Hopefully just 1 step left and I'll be on my way (crosses fingers).

dave :)


     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

David Eaton
In reply to this post by Soren Andersen
No, I haven't move to Vista.  Why?  Even after SP1, Vista 64-bit is crap.  All kinds of goof ball errors.  What I have read indicates that is the 64-bit version alone, but I'm not about to dole out $ just to get a 32-bit version.  For me, for now, XP does what I need, and that is all that is important to me.  I really don't want to argue about this, but if your thesis is correct, then mingw should never have had a XP port.  Really, can't we get away from an arguement that will lead to nothing and instead focus on actually helping people?

Dave :(


--- On Fri, 10/24/08, somian <[hidden email]> wrote:

> From: somian <[hidden email]>
> Subject: Re: [Mingw-users] newbie - can't get include and libs to work
> To: "MinGW Users List" <[hidden email]>
> Date: Friday, October 24, 2008, 9:50 PM
> Quoting David Eaton <gcos7 ~at~ OBSCURED dot NUL>:
> > All of this talk of no spaces sounds great as words -
> but again,
> > look at the platform -> Windows.  Windows not only
> allows it (which
> > says that tools that run in Windows should adhere to
> what it
> > allows) but PROMOTES it by having everything install
> to "\Program Files".
>
> Is _that_ what you can cite as supporting "proof"
> that your contention is correct? That's a shame. Clearly
> you haven't been near the *next* OS release after
> Windows XP yet, or you'd know better than to try to
> dismiss the discussion based on such a shakey, miniscule
> piece of "proof".
>
> The embedded spaces problem is so large and was such a
> mistake on M$'s part that on Vista, Microsoft's
> default, out-of-the-box configuration has soft links that
> alias *space-free path names* to the old spacey ones (left
> there for, of course, backwards compatibility).  Such a pain
> in the kiester problem that _even_ Microsoft, that towering
> edifice of clueless out-of-touchness, got the message.
>
> >  As much as it is nice to talk about "just moving
> things",
> > this in REAL life with Windows is not practical.
>
> Getting a little bit personal for a moment, what I found
> after several years of being a major ass on the technical
> fora online, was that no one wanted to communicate with me
> anymore. I tended to feel things like "these blowhard
> know-it-alls need to be taken down a peg or two" and
> "I won't let them get to me, I know I am right and
> I am going to win this argument." Sound familiar?
> That's the kind of ego-illness that we saw earlier this
> week from Tim S. and now you are doing a great job of
> demonstrating it too. THIS is an example of a strategy that
> simply doesn't serve one well in *REAL life*. Talk to
> someone about this with a determined mind to deal with
> *practicalities* and you'll find that you need to work
> on something more fundamental than libusb, Dave.
>
> You might want to remember that you apparently came to
> MinGW-Users in order to locate and communicate with *some
> folks who might know a bit more than you do*. Apparently you
> are extremely selective about what you'll hear though.
> So...
>
> > Now, enough on that subject, what about helping me
> with my problem?
> Due to the truly mind-boggling, overweening, "I have
> to be right and damn other people" arrogance you are
> displaying, I've completely lost interest in helping you
> with anything else, now or in the future.
>
> > Dave :)
>
> Drifting back to the non-personal, I'll note that C
> (the programming technology) has an automatic notion of argv
> -- that's an array into which the arguments to a program
> are placed. One can easily determine for one's self how
> CMD parses commandlines by writing a simple test program to
> display all elements present in argv.
>
>    Soren 'somian' Andersen :-)
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe
> at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

David Eaton
In reply to this post by Роман Донченко
Roman - see my latest results - you where dead on!!  The only problem I seem to have now is it doesn't like the -L path for some reason.

Thank you SO MUCH for providing a solution to the first of my problems!

Dave :)


--- On Fri, 10/24/08, Роман Донченко <[hidden email]> wrote:

> From: Роман Донченко <[hidden email]>
> Subject: Re: [Mingw-users] newbie - can't get include and libs to work
> To: [hidden email]
> Date: Friday, October 24, 2008, 2:27 PM
> > C:\daves
> stuff\cvsutil\newsrc\temp>gcc *.c -I
> c:\libusb\include -L
> > c:\libusb\lib
>
> You still need to tell GCC to link with the library. Given
> that the library
> is libusb.a, I suggest appending -lusb to the above.
>
> Roman.
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe
> at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: newbie - can't get include and libs to work

Ross Berteig
In reply to this post by David Eaton
On 10/24/2008, David Eaton wrote:
>...
>The other thing worth noting at least to me as that according
>to the "help", gcc doesn't support -I or -L at the command
>line, even though it did seem to take it when in a specs file:

The output from gcc --help is a capsule summary of options. I
have no idea how the GCC developers decided which ones to
include, but they certainly left out perhaps three quarters of
the total set of options supported.

You really need to find a copy of the GCC documentation (info
gcc works at a Cygwin prompt, or try
http://gcc.gnu.org/onlinedocs/ for the horse's mouth). Read the
chapter on GCC Command Options for most of the story. Some of
the rest is hiding in the (almost undocumented) compiler
backends, you might need to try gcc --target-help for details
specific to the target architecture you are using.

That said, almost all C compilers understand -I to add folders
to the list searched by #include, and -L to add folders searched
for libraries named with the -l option. GCC is no exception.

For a concrete example, I have a tiny C program named "min.c"
that attempts to link to the Lua script interpreter installed in
"E:\Program Files\Lua\5.1" (yes, I have no C drive). Compiling
it from the command line is as simple as:

E:...>gcc -I "E:\Program Files\Lua\5.1\include" -L "e:\Program
Files\Lua\5.1\lib" min.c -llua5.1 -o min
E:...>

Leaving out the -llua5.1 causes link time errors saying
"undefined reference to...".  Leaving out the -L causes errors
that GCC (actually the linker, ld) can't find the lua5.1
library. Leaving out the -I causes errors about not finding "lua.h".

All of this is the kind of detail that a quality IDE tries to
hide from new users. If the learning curve is too steep for you,
you might consider switching to Visual Studio (a free edition
can be had) or switching to an IDE that supports MinGW such as
Eclipse. Unfortunately, Eclipse is not trivial for a new user to
get installed and running.

>....
>Then as 1 last test without the trailing slash to the include path:
>
>C:\daves stuff\cvsutil\newsrc\temp>gcc *.c -o dwetest -B
>c:\libsub\include
>In file included from a_start.c:13:
>ops-linux.h:6:17: usb.h: No such file or directory

Again, you need to name both the place to find include files and
the place to find libraries, AND you need to ask the linker to
link against the library. These three requirements are the
reasons for the -I, -L, and -l options in my earlier example.

Ross Berteig                               [hidden email]
Cheshire Engineering Corp.           http://www.CheshireEng.com/


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
123