On Wed, Jan 05, 2005 at 01:58:45PM +0100, Peter Berg Larsen wrote:
+void strarray_set(strarray* arr, int index, const char* str) +{
- if (index >= arr->maximum)
- {
- arr->maximum = index+10;
- arr->base = xrealloc(arr->base, sizeof(*(arr->base)) * arr->maximum);
- memset(&(arr->base[arr->size]),0,sizeof(*(arr->base)) * (arr->maximum - arr->size));
- }
- arr->base[index] = str;
- if (arr->size <= index)
arr->size = index+1;+}
Do we really need this strarray_set() function? Even if you do, it should _not_ shorten the array.
On Wed, 5 Jan 2005, Dimitrie O. Paun wrote:
On Wed, Jan 05, 2005 at 01:58:45PM +0100, Peter Berg Larsen wrote:
+void strarray_set(strarray* arr, int index, const char* str) +{
- if (index >= arr->maximum)
- {
- arr->maximum = index+10;
- arr->base = xrealloc(arr->base, sizeof(*(arr->base)) * arr->maximum);
- memset(&(arr->base[arr->size]),0,sizeof(*(arr->base)) * (arr->maximum - arr->size));
- }
- arr->base[index] = str;
- if (arr->size <= index)
arr->size = index+1;+}
Do we really need this strarray_set() function?
No, but it is convinient to have. I need the fullpaths to the .so libraries at certain point. Basicly I saw two ways of doing what:
1) Call [get|guess|try]_lib_path at the that point.
2) Save all previous result from get_lib_path. So now I need a way to link a file to the full path. The easiest way was to add a fullnames array, which had a 1-1 correspondence with the file array. However not every file has a fullname (fx. a file can also be a include directive), and the call get_lib_path is in a 60+ line foreach(@file)if/switch/else/switch part; so to keep it simple I need a set(index,element).
Even if you do, it should _not_ shorten the array.
Agreed. And the intension was that it shouldnt. I may be code blind, but do you see any way that it does shorten the array? maximum := the allocated array size, size := number of used entries in the array (0 ... size-1)
Peter
On Thu, Jan 06, 2005 at 10:10:50AM +0100, Peter Berg Larsen wrote:
No, but it is convinient to have. I need the fullpaths to the .so libraries at certain point. Basicly I saw two ways of doing what:
Call [get|guess|try]_lib_path at the that point.
Save all previous result from get_lib_path. So now I need a way to link
a file to the full path. The easiest way was to add a fullnames array, which had a 1-1 correspondence with the file array. However not every file has a fullname (fx. a file can also be a include directive), and the call get_lib_path is in a 60+ line foreach(@file)if/switch/else/switch part; so to keep it simple I need a set(index,element).
Makes sense.
Even if you do, it should _not_ shorten the array.
Agreed. And the intension was that it shouldnt. I may be code blind, but do you see any way that it does shorten the array? maximum := the allocated array size, size := number of used entries in the array (0 ... size-1)
Correct, I've read the code in a hurry, and I've read the assignment the other way around.
Of course, there is the bigger problem of why you need these in there. In fact, in the beginning of winegcc, we used to pass them to winebuild, but we've stopped long time ago.
On 6 Jan 2005, Alexandre Julliard wrote:
I'm not sure I follow you, if your .so files have been built correctly they shouldn't contain undefined references to Windows APIs. Could you please show an example of the situation that causes a problem?
On Thu, 6 Jan 2005, Dimitrie O. Paun wrote:
Of course, there is the bigger problem of why you need these in there. In fact, in the beginning of winegcc, we used to pass them to winebuild, but we've stopped long time ago.
Hmm, okay - it seems that I am going down the wrong road.
I have a project with ca. 10 libraries with source, 2 binaery only dll, and 3-4 projects that uses all of these libraries. I have a goal of replacing/porting one of the binaery only dlls. This perticula dll is use all over the place. When replaceing one functionallity at a time from the dll, I want it to be link at one place only (otherwise some libraries would use the real dll, other my reemplentation). Therefor the libraries are just created by gcc -shared -o foo.so *.o, and the handling the symbols are first done when linking to one of the 3-4 projects. Which brings me back to the questions; at the linking time some symbols in the shared libraries might use symbols in the dll, that are not dealt with (used in the project I am compiling).
Does that make sense?
There is might be the road of building the libraries static, which winegcc seems to parse to winebuild.
Peter
-
Dimitrie O. Paun -
Peter Berg Larsen