On September 18, 2003 07:13 am, Richard Cohen wrote:
This is needed for winegcc to build wine itself
- Remove . from default library search path
This may break Winelib apps. Did you check that MinGW does not search . for libs?
- -lwine needs passed in -L paths
What do you mean by this?
strarray_add(lib_files, strmake("-l%s", library));
/* Probably one of:
* .def - which winebuild won't find
* .so - which winebuild doesn't support
* .a - which gcc won't find
*/
fprintf(stderr, "Ignoring library %s\n", library);
We need to pass .a files to gcc, otherwise Winelib apps break. A lot of them (see wxWindows) compile as a big .a lib, and link with that. What do you mean "won't find"? And we should pass .so libs to gcc as well.
Dimitrie O. Paun wrote:
- Remove . from default library search path
This may break Winelib apps. Did you check that MinGW does not search . for libs?
Yes, of course I checked. If any winelib apps break, then they are broken and need fixing.
- -lwine needs passed in -L paths
What do you mean by this?
When using winegcc to build bits of wine itself you cannot rely on the installed location to even exist yet. So you must tell winegcc/winewrap where to find libwine.so using -L. Here is the relevant bit in the patch:
@@ -376,7 +393,8 @@ strarray_add(wspec_args, strmake("%s.exe", base_name)); strarray_add(wspec_args, gui_mode ? "-mgui" : "-mcui"); strarray_add(wspec_args, wrap_o_name); - strarray_add(wspec_args, "-L" DLLDIR); + for (i = 0; i < llib_paths->size; i++) + strarray_add(wspec_args, llib_paths->base[i]); strarray_add(wspec_args, "-lkernel32"); strarray_add(wspec_args, NULL);
@@ -407,6 +425,8 @@ strarray_add(wlink_args, strmake("%s.exe.so", base_file)); strarray_add(wlink_args, wspec_o_name); strarray_add(wlink_args, wrap_o_name); + for (i = 0; i < llib_paths->size; i++) + strarray_add(wlink_args, llib_paths->base[i]); strarray_add(wlink_args, NULL);
strarray_add(lib_files, strmake("-l%s", library));
/* Probably one of:
* .def - which winebuild won't find
* .so - which winebuild doesn't support
* .a - which gcc won't find
*/
fprintf(stderr, "Ignoring library %s\n", library);
We need to pass .a files to gcc, otherwise Winelib apps break.
Yes of course.
What do you mean "won't find"?
This comment refers to the ones that couldn't be found in the library search path. Maybe I should give up putting comments in ;-}
And we should pass .so libs to gcc as well.
Sorry - s/winebuild/gcc/ - of course at the moment winegcc doesn't recognize them.
-- Richard
On September 18, 2003 09:59 am, Richard Cohen wrote:
fprintf(stderr, "Ignoring library %s\n", library);
We need to pass .a files to gcc, otherwise Winelib apps break.
Yes of course.
What do you mean "won't find"?
This comment refers to the ones that couldn't be found in the library search path. Maybe I should give up putting comments in ;-}
And we should pass .so libs to gcc as well.
Sorry - s/winebuild/gcc/ - of course at the moment winegcc doesn't recognize them.
OK, so I'm confused: if we both agree that we should be passing .a and .so stuff to gcc, why are we ignoring these libs? (At this point, I'm not sure at all of the context of the patch, it may be that just the comment is a bit confusing).
Dimitrie O. Paun wrote:
OK, so I'm confused: if we both agree that we should be passing .a and .so stuff to gcc, why are we ignoring these libs? (At this point, I'm not sure at all of the context of the patch, it may be that just the comment is a bit confusing).
The patched code looks like ...
---------------------------------------------------------------- static void sort_lib_file(const char* library) { char *lib;
if (find_dll(library)) { strarray_add(dll_files, strmake("-l%s", library)); } else if ((lib = find_lib(library))) { /* winebuild likes the full path for .a files */ strarray_add(arh_files, lib); } else { /* Probably one of: * .def - which winebuild won't find * .so - which winebuild doesn't support * .a - which gcc won't find */ fprintf(stderr, "Ignoring library %s\n", library); } } ----------------------------------------------------------------
... isn't it clear that the comment refers to libraries that couldn't be found (in the -L library search path).
If you prefer some other comment (or none ;-)), feel free to suggest it.
Perhaps you were deceived by the following line?
- strarray_add(lib_files, strmake("-l%s", library));
The code was just adding stuff to lib_files and then not using it.
-- Richard
On Tue, 23 Sep 2003, Richard Cohen wrote:
... isn't it clear that the comment refers to libraries that couldn't be found (in the -L library search path).
It's fine, thanks for the explanation.